The Website Migration Checklist will forever be “in progress” so add in items that I’ve missed by leaving a comment. At the end of the post is a link to download this checklist as a PDF if you want to print something out.
Groundwork
As early as possible gather together the teams that will have an impact on the final site launch. That may include project managers, design team, development team, user experience, copywriters, account executives, network administrators and possibly even legal if they need to give their approval.
Write on the whiteboard what the problems the new website will be solving. You are planning the migration for a reason, make sure everyone is aware of those reasons and understands why they are important enough to burn the resources to make all this happen. Knowing that the old site struggled with time-on-site or click-through rates will help the teams focus on making those better on the new site.
Plan the terribly expensive meeting for everyone to sit in one room at one time for no more than 1 hour. In that time everyone needs to offer up their concerns. No one can say “I have no concerns” because if they do, they’re lying.
Write all the hurdles down so the next time you meet with any members of the team you can address their concerns. A site migration is a big deal; you’ll need buy-in from the whole team.
Choose a smart day to launch. Tuesday’s or Wednesday’s are best. You can scramble the weekend(s) before if needed and also have a few days after to fix any problems that crop up on launch day. Plan the launch for around 10:30am. It’s after the morning rush of traffic and still allows most of the day to tweak.
What you’ll need from the various teams
Project Management
Map out with time and resources as early in the process as possible. Look at that timeline and compile a worst-case scenario. It will probably add 200% to the cost and up to 300% to the time line. The truth will lie somewhere between the nirvana that we generally dream of and the worst-case scenario that just made you shiver.
The PM will need to keep everyone on target, so it’s vital that she have the confidence of everyone who is participating.
Design
The designers are one of the two notorious factions that can drag out a project. There has to be a vision and a concept for sure, but also remind them that part of their creativity is to make the magic happen within the allotted timeframe. Review their progress at regular intervals with the developers present. Something that seems simple in Photoshop may make a front-end developer pull his hair out.
User Experience Designer
The UXD role is sometimes handed off to design or development, either way it’s a part of the process that is important to hold up as the goal. The UXD will work on wireframes and site structure in a way that can have a huge impact on design, development and SEO. Getting draft copies of the UXD’s ideas out to those 3 teams will head off future pain points.
Development
Don’t let development be the end of the assembly line. Make sure that the people who will be bound by the launch date participate early in process so that their concerns can be heard. It’s imperative that development actively contribute, they cannot sit in meetings and offer nothing of value.
Content Creators (aka copywriters)
You must have a content plan. At its simplest level it may be “we’ll copy all the old content to the new site”. At the more complex level it includes a full content audit involving the web analytics team and corporate branding’s involvement.
Make sure the people tasked with content have the opportunity to tell you how long their job will take. You may not have as much time available as they would like, but you can make a business decision based on quality and quantity by having all the facts in front of you.
Remember to also include time needed for any graphics, audio and video that may need to be added, modified, re-skinned, etc.
Account Executives
Accounts aren’t always included in the migration plan, but they should be. Setting expectation at the proper level is essential to avoid having that last minute freak out that is all too familiar to anyone who has launched a website.
The accounts executive’s job is one of internal and external public relations. Keep the ship on a steady course and everyone happy like a cruise director.
Network/System Admin
Whoever is going to be tasked with getting all your digital ducks are in a row when you throw the switch needs to be kept up to speed on what’s happening. The systems team will need to know if the site needs any security certificates, how many visitors are expected, if there are spikes in traffic expected, etc.
Make sure the PM talks with the sysadmins regularly and gives them the feedback and information they’ll need.
Legal Review
If any of the content on your site needs to be reviewed by an internal (or external) legal review make sure you know their schedule so that you can hit internal milestones to hand over what legal needs.
Site Architecture
Unless you are throwing away the old site and starting from the ground up, you will need to address the site architecture of the move. The bigger your site, the more delicate this can become.
Canonicalization
Decide on some basic rules for the website. Will you be using www.example.com or just example.com? Will your pages have a trailing slash? Once this is decided, you can hand it off to the person in charge of setting up the web server to make it happen. Every page should only answer to a single URL. Use canonicalization to enforce this.
Coming Soon
If you are building up some excitement around the move, consider putting up a page with a “coming soon” type of message that lets people know what’s coming and why they should be exited. The page should be using the robots noindex,nofollow tag so the search engines don’t index it.
URL Structure
If you intend on keeping all (or most) of your existing content, you will want to make sure your new site has a URL structure that is either identical to the old site, or one that is easily grouped to forward visitors using http redirects.
For example, if you had a section of the old site that attracted a lot of traffic at example.com/dogs/sheepdogs/index.php and the new site has example.com/canines/working-dogs/sheep-dog-7216/ that would be a hard one to rewrite in a programmatic way.
But, if the new url was example.com/canines/sheepdogs/ it would be a trivial rewrite and programmatically simple.
This is a place where involving your UXD, developer and sysadmins makes sense.
Content Audit
Not every piece of content on the old site is worth moving over. Below is a list of ways to cull non-performing traffic.
• Has there been even a single visit to a page?
• Are there any external links pointing at the content?
• Has the content ever been shared socially?
• Is there other content that is similar that is doing better?
• Does the content serve a specific purpose?
• Is the content still relevant?
• Is the page orphaned?
The list above will give you a list of pages that should probably just be deleted. There is a much larger list of pages that you will need to think hard about that fall between the hard stops of “get rid of it” and “top performer”. Those middle pages are probably the guts of your site and offer varying degrees of support to your web presence. They should also be culled as follows (many of these metric will depend on site traffic so your mileage may vary).
• If a page isn’t attracting at least 1 visit every day
• If the thought of sharing the page via your social networks makes you cringe
• If there is less than 300 words of content on the page
• Could the content be made more consumable through a graphic or video or some other medium?
• Will the page ever be in the 10% of pages on the site?
These “middle” pages may not need to be removed, more likely they need to be improved. That means adding more/better content, adding video, combining multiple pieces to make one great page.
Changes found during the audit stage need to be communicated back to the UXD who may need to adjust architecture, wireframes, navigation, etc.
Schema.org markup
Make time to add the additional markup to your sites pages that can enhance how the search engines display your information. Use the schema.org markup to semantically structure your pages that have information about:
• Your location
• Events
• People within your company
• Reviews
• Products
The schema.org markup is not much additional work, most of the time it is easily integrated into existing code.
Navigation
Your site’s navigation will have a tremendous impact on how your visitors get around. Go for simple and straight forward. Write it out on a whiteboard and ask for feedback from people not on the project. Make it idiot-proof. Keep in mind that users don’t mind clicking down an easy to follow path, so you don’t need to include everything in your navigation. Be prepared to iterate navigation as you see where the paths get worn .
Map old site to new site
Once you have a complete list of every page from the old/existing site, prepare a spreadsheet including how that content will move over to the new site. This should be done for every url. Pages that are not moving need to be accounted for with either a 3xx redirect or a 404 (Not Found) or 410 (Gone) code.
Also include columns that have the page title, meta description, H1 tag and targeted keyword(s). Use it as a check list to make sure there isn’t any obvious duplicate content .
SEO’s at this point will officially sign off on the page titles, meta tags, content and general on-site factors.
Running Multiple Sites
There will be a time when you will be running more than one site. At the very least, you will have the “new” site in development while the existing “old” site is still handling the everyday traffic.
One step that often gets overlooked is that new content needs to be fed to both sites during this phase. Make sure there is a process in place for that to happen as soon as possible.
In some scenarios you may have a dev, staging and live site for the existing site and the new site. In that case be sure to carve out additional time for content migration.
The New Site Launch Countdown
There is a timeframe for everything as you approach launch date. What follows is a best-case scenario, your actual timeframe will probably not be quite this smooth.
3 weeks from launch
With 3 weeks left until launch date should be the first of many “freeze” dates.
Design Freeze
The first one will be the design freeze. A design freeze means that the design team is basically off the job. There can be no more “suggestions” or “tweaks” at this point. This is the start of crunch time for the website developers and there will be enough stress without design changes being added into the mix.
Authorship
Make sure that the people writing for your website all have proper authorship markup so that their author photos can appear in search results.
2 weeks from launch
Two weeks out will be the time when there will start to be a general sense of excitement mixed with dread. Keep your eye on the prize for the next two weeks. Focus on the core needs of the site. Resign yourself to the fact that something will probably fall through the cracks, but as long as it’s nothing earth-shattering, it’s okay. Continue to move forward.
Content Freeze
This will be easier with some sites than others. Stop publishing new content until the new site launches. This is the time to announce that you have a new site in the works and that it will be launching in 2 weeks – maybe that notice can be your last piece of new content.
Gut Check
This is the date when you ask people if they still feel like they can make the launch date without extraordinary efforts. There will be hemming and hawing, but get a “go” or “no go” from everyone on the team. If anyone says they don’t think they are going to make the deadline, schedule an ad hoc meeting to figure out how to move the obstacles in the way or make a decision to push the launch date.
SEO Check
This is where your SEO specialists need to start crawling the soon to be launched site looking for any problems, but also for opportunities. They can suggest additional linking or tagging, but the titles, meta tags and content shouldn’t be modified at this late date.
Make a final list of redirects that are needed and make sure you test them and that they are as useful and powerful as possible. Using regular expressions within your redirects is the best answer.
Check load times. The pages have to load as quickly as possible . Although the site may not be perfect yet, pages taking over 4 seconds to load need to be optimized to load faster.
Make sure you have your analytics tracking code installed properly on the site. Also set up a profile in Google Webmaster Tools and Bing’s Webmaster Tools.
1 week to launch
Welcome to the scary part of the ride. You now have 7 days to finish what appears to be more than 7 days worth of work. Take a deep breath; it won’t be as bad as it first appears.
This period should be the time when the front-end developer is polishing some minor things and the site moves to QA. That is rarely the truth, so let’s talk about what usually happens.
A lot of functionality isn’t working as expected and the account exec is trying to put a good face on the situation. The 30,000 foot view is that the site looks good and does 95% of everything on the wish list. To the development team who is now working 18 hour days, it seems like nothing is working and the launch date must be pushed another day.
Take a step back and evaluate the situation. The dev team is tired and no longer is firing on all cylinders and the client is giddy about the site going live in a few days. Figure out the truth about what is really happening and if launch is still the best idea for the scheduled date. If it will compromise the quality of the brand, the smart thing to do is slide the launch date. Sometimes the answer is to send the dev team home early to get a good night’s sleep.
If your DNS records have a TTL set to anything greater than 1 day, time to modify it to 1 day.
Structural Network Changes
This is the time to talk with your system/network engineer about preparing the DNS records. DNS records take some time to propagate changes through the network, so this is the time to start adjusting TTL for critical records . On launch day you’ll want to have your TTL set as low as possible.
2 Days before launch
Development has to stop. There will be items on the checklist that are not complete, it doesn’t matter. Add any item that still needs work to the post-launch punch list. All development stops and quality testing starts.
Have the sysadmins set the TTL for DNS records down to nothing more than 4 hours.
Double check the redirects that you’ve developed. Ask a second set of eyes to look them over. Make sure at least 2 system admins sign off that they are concise and will not cause lag in the web server response time.
Run the new site through a service to check load time and potential bottlenecks.
• http://tools.pingdom.com/fpt/
• http://www.websiteoptimization.com/services/analyze/
The day before launch
Last chance to push the launch, although it’s probably too late in reality. Update the “coming soon” page so people will know tomorrow is the big day.
Finish up the QA process while keeping a list of fixes that will start post-launch. Share the list with everyone. Prioritize the list and plan on starting the fixes as soon as everyone has had a good night’s rest.
Set TTL on DNS records to lowest possible minimum in preparation for tomorrows launch . If 30 minutes is an option, choose that.
D-Day – Launch Day!
At the predetermined time, throw the switch on the DNS records if needed and set the website from “dev” to live.
Checklist:
• Site is fully available outside your internal work network
• No links or assets being pointing at the dev site or old site
• Analytics is working
• Start checking the redirects, use a script if necessary
• Log into your Google Webmaster Tools and use the “Change of Address” feature to let Google know your site moved
• Make sure robots.txt is allowing robots to spider your site
• Make sure your site does not have a sitewide noindex tag applied
• Tail the error log and see what is broken , add it to the list
• Return DNS TTL to normal setting
• Pat yourself on the back for a job well done
Launch Day + 2
Start watching the access logs on the deprecated site to see if traffic has dropped off to a trickle. Figure out how to forward any remaining traffic over to the new site on a case by case basis.
You can also start to send the search engines signals that the old site is dead by either adding a noindex tag sitewide, or by adding a sitewide Disallow to the robots.txt
Launch +30 and beyond
The old site should no longer be seeing any traffic. At this point you can check Google to see if it has any remaining pages in the index. For all intent and purposes, the site is now just a shell pushing traffic to the new site.
Print out the ultimate website migration guide and checklist as a PDF document.
Vote for this article at Inbound.org if you found it useful.
