Part 2: Execution

Migrating content for a website relaunch is one of the largest and most important steps on the path to success. Last month, we laid out the planning essentials in preparing for a successful migration. Completing migration in a timely and effective fashion is critical, regardless of the size of the site. This month, we detail the components you need to successfully execute your content migration.

1. Ensure you have the content

Nothing complicates migration like realizing you’re missing content. Suddenly, you’re scrambling to produce content as well as migrate it. Extra communication, approval processes, creative writing, image selection, and deadlines now bog down your migration project.

Before beginning the migration process, make sure you have the essentials. You might not need these for the entire site all at once, but certainly for your priority sections. For example, if program page content is ready to migrate but top-level landing pages are not, consider if you have what you need to migrate the program pages first.

Here are our recommendations for “essential” content:

• Information architecture. This includes knowing which page template to use and identifying URLs for the new pages.
• New content. It should go without saying, but it’s best to have every word written and approved for new pages in advance. This includes page metadata, taxonomy terms, and obvious information such as headings and copy.
• Existing content. When migrating existing pages, be sure to understand the differences or deficiencies you plan to address — for example, missing headings, metadata, or accessibility issues. It’s not unusual for existing content to need some touch-up in order to truly level up with a website redesign.
• Images. Redesigned sites often have more and larger photos. Photo selection and cropping is not a trivial task, and it is best done before migration. Remember to have alt text for each image as well. Both sizing and alt text helps with SEO, too.
• Links. Typically, migration begins without linked menus — it’s difficult in most content management systems to link to nonexistent content. Migrators should plan a second iteration on pages to add links once all the necessary pages exist. Another strategy is to build the “skeletal IA” for all or parts of the site before migrating content. More on skeletal IA later.

The amount of content you migrate is another important lever you can control. But don’t make this decision at the end of your project. Set a clear “minimum viable product” for launch and defer migrating nonessential content in the prelaunch time crunch. This is an extremely valuable tool for controlling schedules.

Migrators want to be able to make decisions about content creation while keeping the process moving quickly and predictably. Regardless of team size or skill level, ensuring content is fully ready to migrate is the key to a stress-free launch.

2. Decide on manual or automated migration

Project stakeholders frequently discuss the merits of an automated-to-scripted migration process versus a manual (copy and paste) approach. While this is really a planning decision, the advantages and disadvantages of these two approaches are rooted in execution.

Spoiler: At mStoner, our starting position is that migration is manual unless proven otherwise. It certainly isn’t one-size-fits-all, but entering a website redesign project assuming there is an easy button that automatically moves existing content into a new design (and sometimes CMS) is fraught with risk.

What are the key considerations for a scripted approach versus doing things manually?

• Scripted migrations work best with well-formatted, consistent content. This rarely works for a full site, but it can work for news articles, faculty/staff profiles, or even standard, lower-level pages with mostly text content. Content that lacks consistent HTML structure or formatting, uses embedded styles, or has a complex layout is typically difficult to migrate successfully in an automated fashion.
• The return on investment for time spent on scripted migration increases with the amount of content. Creating a script to migrate 2,000 well-structured faculty profiles won’t take any more time than creating the same script to migrate 20 faculty profiles. Greater volume of content makes a better case for the scripted approach.
• Most scripted migrations require touch-up. Even when content is successfully moved, many scripted migrations still require: 
  • Review by a human to ensure completeness.
  • Edits or updates to links within the page (because link destinations change).
  • Photography/image additions.
• Website redesigns often introduce new design and features. Automated migrations sometimes can’t take advantage of new features. Often pages migrated in a scripted fashion are “bare bones” pages in a new design.
• Who will do the work? Scripted migrations typically require a developer resource. Manual migration can be done by a wide variety of team members with a little training. Tasking a developer with scripted migration work often further constrains a resource bottleneck on the project.
• Timing. Most scripted migrations block the content from being reviewed or edited until the scripted work is 100% complete. Touch-up or review must happen after the last time the script is executed to avoid losing work. Delays or unexpected challenges can be hard to predict. Manual migration creates incremental progress that stakeholders can review, share, and modify as the migration progresses.

Ultimately, these decisions should come down to time and resources. Suppose it will take 40 hours for a developer to create a script to migrate 300 news articles (plus 10 hours for links and image cleanup). It will take 100 hours to manually migrate those articles. Is it worth the developer’s time? Developers are notoriously optimistic when estimating. What if there are issues with inline styles in some of the articles, and it takes the developer 80 hours? What if there are 20 system bugs the developer could work on instead?

We recommend a conservative and realistic approach for scripted migration work, but it definitely can play a role in successful content migration.

3. Be flexible and iterate

Like any project, website migration requires juggling a lot of moving parts. From content approval to completing system features, one constant remains: Flexible teams must plan for iteration.

What do we mean by iteration? Here are a few specifics:

Build skeletal IA. (Told you we’d get back to this!) Skeletal IA refers to placeholder pages (using the correct URL, title, and page template) within the CMS. Making this the first step in the migration process pays dividends. Migrators begin work with pages that already exist in the correct section of the site. Links and menus can be functional in the system sooner. Building skeletal IA first requires that all pages are touched at least twice (and perhaps more), but this kind of iteration increases the efficiency of migration overall.

Other common areas of iteration include adding images to pages, interlinking, or adding metadata (SEO content) to pages. It is often more efficient to have a migrator focus on just adding images or SEO content so the task is more discrete and repeatable, but this requires iterating on pages.

Page reviewers should be different from page migrators. The formality of final page review (Is there a beta site? Is a broader audience invited to review?) varies from project to project, and there’s no single best approach. However, for best quality, review the final product separately from the migration itself.

4. Anticipate common procedural practices

We’ve migrated enough websites to notice a few recurring procedural practices that are sometimes overlooked. We’re happy to share these few tasks you should anticipate to avoid late surprises:

• Build lists of redirects, or create them in the system as the work progresses. All website redesigns will have redirects (often many of them). As pages are migrated, it is always obvious when a page will need to be redirected because it is moving within the new IA.
• Conduct migration in a staging environment, separate from development. Promote the migration site to production as launch nears in coordination with the migration team and IT. Keeping migration and development activities separate, while maintaining a smooth workflow for developers to deploy code changes and fixes to the migration environment, is essential to minimize blocking issues.
• Use an image naming scheme. Naming schemes can help identify correct locations when you’re uploading in bulk. This image work can be a separate iteration from the migration itself, but it needs to be clear to the folks putting images on pages where they should go.
• Freeze content. Once content has been migrated to the live sites, lock it down so it doesn’t get out of sync as you progress. Or track critical changes so the change can be made in both places. Nothing is more frustrating than content feeling like a moving target because it changes after it has been migrated.

5. Track your progress

Tracking progress and assignments is critical in avoiding rework, gaps, and surprises. The tools need to fit the project, and here are some of our favorites:

• A tracking document that lists pages to migrate (by URL), status, review needs, outstanding tasks for a page (connecting links, adding images, etc.), required redirects, and other details. A shared document such as Google Sheets is much better than a file that gets passed around in email. Existing pages that will migrate as-is are often tracked effectively this way.
• Use a tool such as GatherContent to stage new content. This is a great environment for content creators and includes robust steps for content review and approval. GatherContent also allows users to include status steps for the migration process. This works particularly well for modular and complex pages with specific content needs. Users can build templates to map content needs to new templates and designs. Images, taxonomy, metadata, links: Virtually everything a migrator will need can be added in a tool like this and tracked as it proceeds from content development to live webpage.
• File sharing tools such as Dropbox or Google Drive are helpful for storing images, PDFs, video, and other assets to migrate. Strong organization and naming conventions help make these assets easy for migrators to add to migrated pages.

6. Prepare for launch

Migration is the last major step before site launch. But launches can be delayed when there’s no clear end or transition plan. It’s important to remember that it is not uncommon for website redesign projects to launch in phases.

Pivoting from migration to launch preparation brings activities from migration into the tactical task list for launch. Things to consider at this stage are:

• Conduct a final review. Whether a weeks-long beta site preview or just a few days of final QA, plan to freeze migration, remove test content, make final checks of key functionality, and get ready to launch. Remember that the work isn’t done at launch. Many website redesigns include multiple phases of content migration, and the project to process transition begins at site launch.
• Review website accessibility. Website projects have checkpoints for accessibility in design, HTML code construction, and content. Accessibility is always an ongoing concern on websites, but checking accessibility of pages after migration is a key launch readiness step.
• Ensure redirects are in place within your CMS and within code added with IT’s help. Be ready to add any that emerge after launch. Redirects are key to SEO and, while often technical in nature, they are key content elements that ultimately are implemented and tested with the site launch.
• Use a checklist. It’s helpful to have a checklist of things necessary for launch. It should include things at the intersection of content and functionality such as site search, web forms, 404 page, robots.txt crawler directives, and links or integrations with external sites/systems.

It can be difficult to decide when a major website redesign migration effort is “done enough.” Avoid letting perfect be the enemy of good and focus the migration on getting to a successful launch, not on perfection.

Content migration is a heavy lift, and a launch is an occasion to celebrate. There is virtually always more work that can be done, and feedback from the community to anticipate. Have a plan for feedback, but expect more kudos than complaints even if there are some squeaky wheels. When it’s all said and done, take a break and celebrate the launch!

We’d love to celebrate a website launch with you. Let’s chat about options.

Read Part 1: How to Prep Your Content for Migration