Site Migration Checklist US version
A comprehensive guide to a successful website migration process. Regardless of the size of your website a migration can be nerve-wracking so here are some tips on how to do it well.
When preparing for the final site launch, the first main task to be done is the gathering of the teams that will be working on it. The teams that will have an impact on this final site launch may include: design team, project managers, user experience designer, development team, account executives, copywriters, network administrators. In some cases the legal team may need to be called in case their approval is needed.
Gathering all the teams and experts for a one hour meeting should be the next step. During the meeting every team can share what their concerns are. Every team should be encouraged to speak up, because it is guaranteed that they would all have some sort of question or concern.
It is important to write down every hurdle. That way, during the next meeting the concerns of every team member can be addressed and dealt with. Site migration is a big task and that is why the cooperation of all teams is so crucial.
Next step is to choose the launch day. Midweek is the best time – Tuesday or Wednesday. This way you have some days left over if there are any problems that need to be fixed. The best time of the day to launch is after the morning rush – around 10:30 a.m.
Things that you will need from the different teams
It is very important that the resources and time scales are outlined very early in the process. Always have in mind a plan of action if the worst is to happen. That way you will be prepared that there might be a huge addition to the cost and the timeline. Normally the reality is a mix of hiccups and the best scenario we can think of.
The role of the Project Manager is to keep everyone focused on the target. That is why it is very important that everyone that is participating has confidence in them.
The designers are normally the ones that can really make a project seem endless. Their concept and vision are important factors, however, what they need to remember is that they have to be creative keeping within the time frame that was allotted. It is good to review the progress they are making with the developer’s presence. You can do that at regular intervals to make sure everything is going smoothly.
User Experience Designer
Very often this role is passed on to the development or design team. However, it is still an important part of the process. The work of the UXD will have a huge impact on the SEO, development and design. It is advised to keep sending copies of the ideas of the UXD to those 3 teams. That way you will save some headaches in the future process.
The development is a very important part of the site migration. It shall by no means be left for the end of the assembly line. It is important to have the people involved to participate at the very beginning of the process. That way, if they have any concerns, they can be heard and dealt with. When meetings are held, the development team is expected to actively contribute ideas and suggestions of value1.
Content Creators (aka copywriters)
Here a content plan is a must. The simplest thing that can be done is to copy everything from the old to the new site. However, sometimes more complex measures have to be taken. That means involving the corporate branding and the web analytics team in order for a full content audit to take place.
It is imperative that the content team tells you how long it will take them to do their job. You may have a different time scale in mind for executing the project and that is why this information is important so the best business decision based on quality and quantity can be made.
Make sure you add some extra time for any graphics, audio and video that may need to be added, re-skinned, modified, etc.
Usually the accounts are not included in the migration plan. However, they are an important part and they should be included. In order to avoid any disappointments and panic at the last minute, it is vital to set expectations well on time – at the proper stage of the migration task.
The account executive’s job is to deal with internal and external public relations. That is why it is important to keep the process very smooth to keep everyone happy2.
The network/system admin needs to be kept up to speed with what is happening. In order for the system team to do their job they will need to know how many visitors are expected, does the site need any security certificates, are there spikes in traffic expected, etc.
Here it is important to keep up good communication between the Project Manager and the system admin so feedback and information can be exchanged.
In case you have content on the website that needs to be reviewed by an internal or external legal reviewer, it is vital to know their schedule so you can manage and hand over what the legal department need.
In most cases there will be a need to bin the old site and start a new one from scratch. In this case you will need the site architecture team on the job. If the site is big, the job becomes more delicate.
During this process you will need to decide on some basic rules for the website. Are you going to use www.example.com or just example.com? Are you including trailing slash in your pages? Once you make this decision, you can hand it off to the person who is in charge of setting up the web server to make it happen. You need to use canonicalization3 to enforce that every page answers to a single URL.
Most of the times you will be building up some excitement around the move of your site. If you are going to do that then you need to consider putting up a page with a “coming soon” type of message. By doing this, you will let people know what is coming and the reasons they should be excited. The search engines won’t index the page if you are using the robots noindex, nofollow tag4.
The URL structure will depend on your decision if you want to keep all or most of your existing content. If that is the case, your new site needs to have a URL structure that is either identical to the old site, or one that is easily grouped to forward visitors using http redirects5.
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 difficult one to rewrite in a programmatic way.
However, if the new URL was example.com/canines/sheepdogs/ it would be an easy rewrite and programmatically simple.
Here you should involve your UXD, developer and system admin.
In most cases some of the content on the old site is not worth moving over. Below is a list of ways to pick non- performing traffic.
- Have you had at least one visit to a page?
- Have you got any external links pointing at the content?
- Have you ever shared the content socially?
- Have you got similar content that is doing better?
- Is there a specific purpose for this content?
- Is this content still relevant?
- Is the page orphaned?
Answering the above questions will give you a clear idea of the pages that need to just be deleted. You will also have to make another list including the pages that are neither for deletion nor they are top performers. Those middle pages are important for your site and offer different ways of support to your web presence. They should also be picked as follows: (Remember that many of these metrics would be dependant on site traffic so your mileage may vary).
- Is the page attracting at least 1 visit per day?
- Do you cringe when you think of sharing the page via your social networks?
- Is the content of the page less than 300 words?
- Could a graphic or video or some other medium make the content more consumable?
- Will that page ever make it in the 10% of pages on the site?
Removing those pages may not be necessary. In most cases, those pages need to be improved by adding more and better content, video, and all in all combining many pieces in order to create one great page.
If any changes are found during the audit stage, the UXD need to be informed about them so they can adjust wireframes, architecture , navigation, etc. if needed.
It is important to add the additional markup to your site’s pages because that will enhance how the search engines display your information. Use the schema.org markup to semantically structure your pages that have information about:
The schema.org markup is not going to create much additional work. Most of the time it is easily integrated into existing code.
It is very important that your site has good navigation because that will have a huge impact on how your visitors get around. The best you can do is simple and straightforward navigation. To get a better idea you can write it out on a whiteboard and get some feedback from people that are not involved with the project. Make it idiot-proof. Users would not 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 worn11.
Map old site to new site
When you are ready with the list that includes the pages from the old site, you should prepare a spreadsheet in which you should describe how that content is getting transferred to the new site. You have to do this for every URL. Even the pages you have decided not to move you have to account for. This can be done with either a 3xx redirect12 or a 404 (Not Found) or 410 (Gone) code.
To make sure there is no obvious duplicate content, you should include columns with the page title, meta description, H1 tag and targeted keyword(s)13.
The SEO at this point will officially approve the page titles, meta tags, content and general on-site factors.
Running Multiple Sites
At some point in time it can happen that you are running more than one site. You will at least have your old and new site to manage. The old one will still be handling everyday traffic whilst your new one is undergoing development.
When you are in that phase you have to make sure there is a process in place for both sites to be fed new content. In some scenarios you may have a development, staging and live site for the existing site and the new site. If you happen to be in such a scenario, be sure to make additional time migration of content.
The New Site Launch Countdown
When you are approaching the launch date, there is a time frame for everything. Normally we all want the best case scenario to happen, however, your actual time frame will probably not be quite this smooth.
3 weeks from launch
When you have 3 weeks left until launch date, you should have the first of many “freeze” dates.
The first freeze has to be done on the design. This means that the design team should have finished their job and they can no longer make any “suggestions” or little “tweaks” at this point. When you have 3 weeks to launch the website developers are starting to feel the stress and that is why they don’t need any additional design changes.
2 weeks from launch
At that time you will definitely start to feel the excitement and the worries. Remember to keep your mind focused on the goal for the next two weeks. You have to concentrate on the core needs of the site. Prepare yourself that something unexpected might happen and hiccups are expected but as long as they are not major, it’s okay. Keep moving forward.
This can happen easier for some sites while for others it can take some more effort. Now is the time to stop publishing new content and also is the time to announce that you have a new site on the way that will be launched in two weeks.That notice can be considered as the last new content on your site.
This is the time when you have to check with every team whether they still feel positive that the launch date is realistic and that is not going to cause them any extraordinary efforts. You need to be firm here and get exact answers. In case somebody says they don’t feel positive and think that they are not going to make the deadline, you have to schedule a special meeting to decide how to move the obstacles in the way or make a decision to change the launch date.
This is the time when your SEO specialists have to start checking the site looking not only for any problems, but also for opportunities. They can make suggestions for additional linking or tagging, but at this late date it is not advised to change the page titles, meta tags and content.
Prepare a final list of redirects that are needed. You have to test them to see that they are as useful and powerful as possible. Using regular expressions within your redirects is the best answer14.
Checking loading times is crucial. Your pages should load fast. Even though the site may not be perfect yet, all pages that take more than 4 seconds to load must be optimized to load faster15.
Now is also the time to make sure you have your analytics tracking code properly installed on the site. Setting up a profile in Google Search Console and Bing’s Webmaster Tools should also be done at this stage.
1 week to launch
This is truly the scariest part of the whole process. You have seven days to finish any outstanding work.
This is the time for the front-end developer to polish some minor things and the site
should move to QA. However, usually things don’t go as smoothly as that.
Imagine if a lot of the functions aren’t as expected. The account executive is painting a bright picture that the site looks very good and does 95% of everything on the wish list. However, the overworked development team seems to think that nothing is working and the launch date should be pushed.
Evaluation of the situation is urgently needed. You may find out that the development team is tired and no longer has the energy to give 100%. On the other hand you will see a client that is extremely excited about the launch of the site in a few days. It is time to figure out what the best move is. If you have to compromise with the quality of the brand, then the best thing to do is to change the launch date. Sometimes the development team may just need a good rest.
If your DNS records have a TTL set to anything greater than 1 day, it is time to change it to 1 day.
Structural Network Changes
Now is the time to talk to your system/network engineer about preparing DNS records. These DNS records take time to propagate changes through the network. That is why this is the time to start adjusting TTL for critical records16. Your TTL should be set as low as possible for the launch date.
2 days before launch
At this point development has to stop. Of curse, there will be items on your checklist that are not complete. That doesn’t matter. Any item that still needs work should be added to the post-launch list. Once all development is stopped the quality testing should start.
The system admin should set the TTL for DNS records to no more than 4 hours.
It is time to check the redirects that you have developed. You should ask somebody else to look them over. At least two system admins should confirm that the redirects are concise and will not cause lag in the response time of the web server.
You should run the new site through a service to check loading times and potential hiccups.
The day before launch
If you are still not ready, now is your last chance to push the launch. It is time to update the “coming soon” page. That is how you will let people know that the big day is tomorrow.
The QA process should be finished now. Keep a list of fixes that need to be taken care of post-launch. Share the list with everyone and plan on starting the fixes in a prioritized order.
You have to set TTL on DNS records to the lowest possible minimum when you are preparing for tomorrow’s launch17. The best you can do is choose the 30 minute option if possible.
At the chosen time, change the DNS records if needed and set the website from “development” to live.
- Make sure that the site is fully available outside your internal work network
- Make sure that there are no links or assets pointing at the development site or the old site
- Make sure that analytics is working18
- You need to check the redirects; if necessary use a script19
- Inform Google that your site has moved by logging into your Google Search Console. Use the “Change of Address” feature20
- Make sure robots.txt allows robots to spider your site21
- Make sure there is no sitewide noindex tag applied to your site
- Track the error log and check what is broken22
- Make sure you return DNS TTL to normal setting
- You can take a deep breath as the job is well done
Launch Day + 2
Now is the time to watch the access logs on the deprecated site. Once this is done, you can see if traffic has dropped off to a minimum. Work out a way of forwarding any remaining traffic to the new site.
Send the search engines signals that your old site is dead. This can be done by either adding a noindex tag sitewide, or by adding a sitewide disallow to the robots.txt.
Launch +30 and beyond
At this point your old site should no longer have any traffic to it. Check Google to see if it has any remaining pages in the index. The old site now should be sending all traffic to the new site.
1 http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a- factor-of-2-3/answer/Michael-Wolfe