You are here

Digital redesign, migration, or rollout in five steps

A strong process for a redesign, migration, or rollout doesn't just look at one dimension (for example, just design), but looks at the relationships, team, tools, and pages that truly make a large site happen. First we look at these, and then the steps of a migration are covered: Vision, Plan, Pilot, Implement, and Maintain.

We need to define what we are attempting to accomplish, potentially facing tough decisions, and need to ensure we can pull it off.
We need to define a plan of how to accomplish our vision, including estimating effort level.
The pilot concretely tests our assumptions. 
During implementation we must be clear and methodical.
We must manage for high quality ongoing change.

It’s not just the design, or just the content, or just technology....

Sometimes, a site redesign really is just that, meaning some templates or CSS changes and that's it. Or it really is just migrating content into a new system. Let's face it: that's rare, except for small or relatively new sites.

One way of looking at this is that the Compelling Vision defines why you are doing the redesign/migration, the pages define what you want, the relationships are a blend of what you want and how you will accomplish it, and the people and tools are all about how you will accomplish it.

The compelling vision is WHY, the pages and relationships are WHAT, and the rest is HOW

Below I'll start with things that might not get planned for (at least sufficiently) during a migration effort. All of the components are related (for instance, good metadata probably means good training for people), but it's probably a good idea to isolate each of these to make sure they are covered. 


By relationships here I mean metadata, structured content, links, and integration with other systems (for example social media and public repositories of information, but also your partner sites) -- basically how your content lives in the site and world. These things aren't plug-and-play in any system, because they are always unique to your organization. For metadata, there is defining the metadata, setting up the tools to support your metadata, training on metadata (both how to use the tool and how to tag effectively), and possibly writing guides on how to use metadata. The reason that metadata and other relationships are becoming more and more important is that your content is appearing automatically in more contexts, both on your site (slicing and dicing by topic for example) as well as off your site. Designing for these relationships is more subtle than may be obvious (for instance, false precision and taxonomy mappings). The point here is that you need to plan for all of these relationships so that you do not box yourself into an implementation that cannot allow the functionality you need.


Your site visitors need to be considered in a redesign (see Jakob Neilson's Fresh vs. Familiar: How Aggressively to Redesign), but here I concentrate on other important people: the team that will implement and maintain your new system. There are two parts to making sure your team will be ready: a) having the right people (and availability of those people), and b) communicating /training these folks. See Staffing a Team for Large Web Site Migration and Training During CMS Migration for more.


Many casual conversations about technology amount to name-dropping ("I just installed FlamingoDogCMS at home last night, and it's much better than the system we use"). People have strong opinions about technology, but hopefully you can steer toward substantive requirements that drive your technology (see Where's the juice in your requirements?). In the case of strongly content-driven sites, you need someone who has experience to help steer clear of potential issues in these technologies specifically (for example around automatic pulls and content re-use). See Should I Stay or Should I Go for more details on the configuration, templates, and special functionality that you should make sure to plan for.


The Page receives perhaps the most attention, since it is in everyone's face and also very concrete to discuss. User interface, information architecture, content strategy and design are discussed in detail elsewhere. These are all crucial aspects and need to be defined for your project, but please make sure to dig into enough details to figure out how to deliver the desired pages.

Also, note that even the technical migration isn't just about pages (see Why It's Hard to Migrate Content).

Migration in Five Steps

Note that I didn't say five easy steps :-). That said, projects may focus on just certain phases (especially ignoring the pilot or maintenance), so listing out generic steps below may help in deciding whether you have addressed them sufficiently for your particular project.

1. Vision

You need a reason for going through the effort of a migration or redesign. The implementation probably will not be easy, so you need to define a compelling vision to align everyone and also remind everyone why you are doing this in the first place (see Compelling Vision for a Large CMS Migration).  Read more on Vision.

2. Plan

Your plan needs to consider all four components listed above, along with the next steps in the process: the pilot, implementation, and maintenance. Part of the planning is defining exactly what you are attempting to implement, but also more about how it will be accomplished. Obviously you will encounter unexpected issues, but hopefully the planning will help reduce those -- furthermore, by clearly planning you may be able to articulate what you are *not* doing as well (think about putting your web site on a diet).  Read more on Planning.

3. Pilot

The objective of a pilot is to better estimate how long the actual implementation will take, enhance buy-in, and give you time to tweak the system before proceeding to implementation. For more information, see The Pilot in a Site Redesign or Migration: A How-to Checklist.  Read more on Piloting.

4. Implement

At some point, someone declares "enough is enough, it's time to migrate". Sometimes you're ready, but usually it's just time to take the plunge. Hopefully you've been able to plan, pilot, and appropriately scope the project. In staffing a migration, you will want two particular roles filled for the actual implementation: project management to track through and push the implementation, as well as product management to maintain overall quality (and also to keep scope under control when issues arise). Note that during implementation the process for dealing with enhancement requests is crucial so that you don't end up building an unsustainable beast (see Be Ready: Initiating CMS Migration as well as CMS Implementation: Product or Project Manager?). You will also want to insure quality during migration, and decide how to track progress during migration (hint: it's not just about pages).  Read more on Implementation.

5. Maintain

Maintenance isn't part of the migration per se, but the migration would be a failure in my opinion if the implemented system cannot be maintained. What are some of the reasons that a site can't be maintained:

Read more on maintenance.  

The migration plan needs to pull all this together

Do you have someone on your team who is committed to looking at all aspects, or are they really in one of the slivers above? If working with a systems integrator, are they looking at how to get to delivery or setting everything up for ongoing success of your site?

A typical (but not ideal) project might go something like this (in the graphic, darker boxes mean more emphasis: for instance, a typical project might have no visioning of the impact on people):

At different stages different aspects should receive more and less attention.
  • The information architecture and design gets the most attention (with probably less attention on the content) in visioning and planning. Or, this could be flipped and if the technical team is running the show then the planning around the technology might get a lot of attention with little attention to IA/design.
  • If there is a pilot at all, it probably focuses shallowly at a technical level rather than a comprehensive pilot. Or, there is a pilot but not enough time to react and make changes based on the findings from the pilot.
  • Implementation just has to get done, but if all the components weren't planned, then items get jettisoned during implementation. The people impacts are probably only minimally considered (with everyone left wondering how their job will be impacted).
  • Maintenance?

The point is that you want to be looking at your migration as a coherent whole rather than isolating one component or attempting to skip steps.

[update: these five steps are explored more fully in my handbook -- download Website Migration Handbook v1 for free, or buy the improved v2]

Breaking down digital silos
Platinum Use Case: Optimizing Content Broadly and Over Time
Golden Use Case: Easy, Day-to-Day Publishing
Content Management Use Cases: The Medalists
Rethinking the Content Inventory: Seven steps to an effective inventory
The "Build It And They Will Come" Fallacy
Lemurs and lions: why you shouldn't leap to implementors
Problem duplication: how bad is it?
How to move from buzzword bingo to real innovation
Redesigning An interview with Josh Tong
Quality and content migration
Beyond forklift and nuclear content migrations
Why, when, and how much migration planning
Content migration — easy, or better?
Four Types of Digital Presence Change
We can't avoid redesigns. We can only lengthen the gap between them.
Decide early: go big or go home?
Content migration isn't like moving day
Early warning signs during big digital change
Don't defer complexity
You can't add your way to innovation
Coherence: consistent & connected
What is problem duplication?
Rethinking the Content Inventory: image aspect ratios
What's your number? The potential extent of web change impact.
Communicating website migration concerns
Visualizing the impact
Cheer or jeer? Did that slick new website help?
It's not (only) about the site visitor
Flexibility: get focused
The nuclear option? Migration planning is more subtle than that.
Thinking of making big website changes? Do you pass the laugh test?
A content inventory is NOT (always) a mind-numbingly detailed odyssey
What could go wrong? Migration train wrecks.
Enemies of rewarding near misses
When content doesn't fit: checking migrated content
Standards aren't defined, they're architected
Rethinking the Content Inventory: quality
Content froth
Focus first (not UX first, content first, technology first, etc.)
Castles and tents
Rethinking the Content Inventory: topic inventories
Standardization and migration effort
Migrating an interview with Bill Trevor
Focused team engagement and the alternatives
Rethinking the Content Inventory: layers of content
Migrating an interview with Chris Contakes
Rethinking the Content Inventory: site inventories
Estimating migration effort: the six steps of handling content
Migration isn't great training
Should you automate your migration?
Rethinking the Content Inventory: sources of data
You're willing to pay for the feature? So what?
Rethinking the Content Inventory: exploration
Site launches: do as little as possible
Content migration burden: it's not just automated or manual
Content migration: what can be automated and what must be manual
Content migration is interesting, really!
Rules for content migration: panning for gold
From vision to use cases for selecting a CMS
The metadata sweet spot
Shock and awe or tightly focused requirements?
Confusing your pilot / beta users before full site migration
Pilot what? Deciding what subsite to pilot before full site implementation or CMS migration
How to migrate content into a CMS
CMS proof of concept, pilot, migration
Should I stay or should I go? Corporate site migration, redesign, or both?
Where's the juice in your requirements?
Staffing a team for large website migration
Ensuring quality during site migration
Tracking website migration progress
Training during CMS migration
Hardest or easiest? Move toward the compelling vision
Content re-use: roles, consistency, and standards
The Web Diet: how to simplify your website
Why it's hard to migrate content
Standardization and large websites
Administrative title
Budging the boulder
Unicode and UTF-8
"Just like current system"