A Guide On CMS Migration

As the internet and technology is ever evolving and improving it often requires us SEO to adapt and change our organic strategies, therefore it’s inevitable that at some point a client will be in need of a website migration. The purpose of this guide on CMS migration is to clearly outline the process that should be used when implementing a content management system migration.

What is a website migration?

A website migration is used to describe when a website undergoes significant changes often relating to the website’s platform, design, structure or location which results in the website essentially being picked up and moved, upgraded or merged. 

It’s vital that these are completed by following a clear step by step process to ensure no mistakes or errors are made. If a website migration is carried out incorrectly it can result in a substantial negative impact to the website organic performance and revenue which could last for several months or if it goes unnoticed the damage could last years.

Types of website migrations

• Protocol Changes – The typical example of this is when upgrading a websites SSL and therefore migrating a website from HTTP to HTTPs.
• Domain Changes – This is usually required when a business is rebranded and as a result must move from one domain name to another. Another reason for this type of migration is when changing theTLD e.g from .co.uk to .com.
• Site Structure Changes – This migration occurs when a website’s architecture changes impacting the URL structure and internal linking.
• Subdomain and Subfolder changes – A common example of this is when a business has a resource hub sitting on a subdomain which then gets migrated with the main version of the site.
• Content Management System changes – This is when a website moves from one CMS to another for example migrating from Magento to WordPress.
• Site Redesigns – Typically this happens when significant design changes are carried out resulting in changes to a websites code, content or media. 

Potential CMS Migration Issues 

It is important to remember that not all content management systems have the same features and therefore this will need to be considered when switching to a new CMS. Below is a list of the potential CMS migrations issues you may encounter:

Plugins – Most CMS have the ability of plugins however the exact same plugins used for your current site may not be available. A common example of this is if your current site is on WordPress and you’re using plugins to automatically generate the schema mark-up, it’ll be important to find another content management system that has this capability or you’re able to find a solution e.g add the schema in the code. 

Service Files – When considering a new CMS it’s vital to review their service files such as the sitemap and robots.txt file to see if they are editable. For example if you’re choosing to migrate to Shopify it important for you to accept that you can’t edit the robots.txt and XML sitemap. 

URL Structure – Some content management systems will change your URL structure,for example Magento 2 by default requires the category path for product URLs and therefore this will need to be included when mapping out the redirects. 

Metadata Rules – Another problem you may face is being unable to include custom meta data. For example when using HubSpot or Passle you’re unable to have a different page title to the h1. 

Website Migration Process

When migrating a website the process shouldn’t be rushed as it’s essential to complete each of the seven stages currently to reduce the risk so the migration can be a success. 

I personally think the best way to picture a CMS migration is using a bridge. The left hand pillar represents the old CMS, the bridge’s right pillar is the new CMS and then the arch way symbolises the gap between the two systems whereby a number of actions need to be completed. 

Step 1: Carry out analysis on the potential new CMS features

Before making any decisions on which content management system to move to it’s extremely important to have a clear understanding of each CMS features to prevent being blinded by certain aspects not being editable or possible to implement. 

If the new CMS you’re considering includes a custom build it’s highly likely that there will be little to no information available on the functionality, however outlining what SEO requirements are needed from the list below is essential so that they can be included in the building phase. 

It’s key to analyse the following components: 

• XML Sitemap
• Robots.txt
• SIte Architecture
• URL Structure
• Canonical Tags
• Pagination
• Hreflang
• Structured Data
• Metadata
• Customisation
• Meta Robots

Step 2: Run a site audit crawl using either Ahfres or SEMrush

The purpose of step two is to gain an understanding of the website size as well as uncovering any current technical problems that you don’t want transferring to the new CMS. E.g a number of pages including two meta descriptions or several pages which include self-referencing canonical which should actually be pointing to a different page. 

With regard to compiling a list of all the sites URls it’s important to export this data from a range of sources such as exporting the URLs from the site audit crawl, running the site through a tool like Screaming Frog and exporting the pages as well as collating all the URLs from Google Search Console pages export and Google Analytics pages export and finally getting a list of the pages referenced in your XML sitemap. Once all of the exports have been completed the data will then need combining in a spreadsheet to then remove any duplicated data and save a copy of this to be used later.

Step 3: Create a backup

Once you have fixed any of the technical issues which were flagged in step 1 that you don’t want transferring to the new content management system it’s paramount you or the web developers take a backup version of the website. If for whatever reason the migration goes horribly wrong the backup version can be used instead, obviously this isn’t ideal as damage will have been done to the organic performance in addition to being back using your old CMS.

Step 4: Map out redirects

From the information and data collected in steps 1 and 2 it’ll be clear as to whether moving to the new CMS impacts the current URL structure. If this is the case it’s vital to map out 301 redirects to ensure the old URL doesn’t return a 404 error. 

To map the redirects out I recommend taking all of the URLs from step 2 and placing them in column A which can be titled as ‘old URL’ on a  spreadsheet the using column B of the same sheet to outline the action required e.g redirect or leave and then column C is where you populate what you’d like your new URL to be on the new CMS.

Once all URLs have been assigned with an action and the new URL it’s important to then filter that data so that only URLs which are being redirected are displayed in the spreadsheet to then be sent to the web developers. The reason for initially mapping out all URLs even if they’re not changing is to ensure that no page is missed out by human error causing it to later return a 404 error. This can then negatively impact the websites bounce rate and conversions which could potentially lead to a loss in revenue, rankings drop and search visibility diminishes.

Step 5: Test the staging site

Before the site gets put live on the new CMS it’s crucial to carry out some pre-live tests on the staging version of the website to minimise the risk of SEO errors or technical problems being flagged when it’s live on the new CMS. 

As the new CMS is sitting on a staging/test website it’s important that this version isn’t in search engines index. This can be avoided by making the staging site only available for a specific IP address, making the staging site password protected or using the robots.txt file to make the site uncrawlable.

Ideally in this pre-launch testing phase includes reviewing each of the aspects listed below:

• Site Architecture 
• Internal Linking
• Metadata
• Robots.txt 
• XML Sitemap
• Canonical Tags
• Meta Robots
• Structured Data
• Javascript Crawling
• Mobile Usability 
• Tracking
• Redirects

It’s not unusual in the testing stage for issues to be highlighted and then fixed. Once these have all been fixed it’s recommended that another review of the staging site is carried out to ensure the staging website is ready to go live. 

Step 6: Website is put live

As soon as the staging site has been pushed live it’s extremely important to make some final checks:

• Check the website robots.txt file to ensure search engines are able to crawl the site.
• Check if all redirects are correctly working. This can be done by uploading your mapped out 301 redirects list in Screaming Frog.
• Review the site’s canonical tags.
• Check to see if any unintentional noindex and nofollow directives have been implemented to ensure the pages can be indexed.
• Compare the tracking code on the website to Google Analytics account tracking code to ensure the website is being correctly tracked.
• In Google Analytics make an annotation of the migration data to make it easier to analyse the post migration data.

Step 7: On-going monitoring

Unfortunately to determine if a migration has been successful requires you to wait some time before measuring this as when the initial change is made it can result in fluctuations which can be very volatile even if everything has been done correctly as search engines needs to re-analyse the new site and the greater amount of structural changes made the longer it may take. However in instances it can be clear to see a migration has not been successful within a couple of weeks due to a catastrophic drop in rankings, traffic, visibility, conversions, clicks and impressions.

Quite often key business stakeholders main focus of a migration is whether there’s been a loss in revenue, however the are a number of factors that can also contribute to a loss in revue:

• Seasonal trends
• Lower brand interest
• Mobile performance
• User exence
• Site speed

As a result of the factors listed above it’s important to pay attention the below to help establish if the migration has been successful:

• An increase in the average duration on a page or the site
• The bounce rate lowering 
• Organic visibility increasing for both mobile and desktop
• An increase in the number of sessions for pages
• Desktop and mobile rankings improving
• An increase in conversions

Summary

Overall a CMS migration is a risky complex task requiring multiple teams to work together, over communicate and educate each other to ensure the transition is seamless.