What is a CMS migration?
Simply put, a content management system (CMS) migration is the transfer of a website’s CMS from one to another. More specifically, this process involves moving a website and its assets to a different CMS than it is currently using, the goal of which usually is to transition to a more desirable platform.
We’ve included plenty of reasons for migrating later in this guide (see section ‘Benefits of a CMS migration’). However, all migrations are also inherently risky; although the level of risk will differ based on what’s changing.
Other types of migrations
There are several types of site migrations, each addressing unique needs and desires a business may have.
CMS migrations are one type of migration. However, depending on the project, several other types may or may not be involved when migrating a website’s CMS.
Domain migrations
Transitioning from one domain (example.com) to another (exampletwo.com) is one of the most expensive and complicated migrations, which presents a unique set of challenges a business needs to overcome. This is because every URL on the site – including the homepage – will change, which can be very risky. This type of migration is most common when a business is undergoing a re-brand because most businesses include their brand name as part of their website’s domain name.
Fortunately, this type of migration is simplified when only a website’s domain name is being changed, and its URL structures remain the same. In this instance, a catch-all, global redirect can be used to perform a flat redirect from the old domain to the new one.
If you’re considering changing the domain name of your site, one of the most important steps will be to report this change to Google within Search Console, using the ‘Change of Address’ tool (example below), but often there is far more nuance to the operation which requires specialist support. You can read more about that here.
URL structure changes
When migrating from one CMS to another, URLs might be subject to change, or a business might choose to change a website’s URLs for certain benefits, for example, shortening URLs for readability, fixing incorrect URLs, or future-proofing URLs.
For example, migrating from WooCommerce to Shopify may require changing specific ecommerce URLs. This is because – to show one example – Shopify requires the inclusion of /collections/ as part of the URL structure for all product category pages. Additionally, Shopify does not allow sub-directories as part of product category URLs (for example: /mens-shoes/trainers/white), as there is no functionality to set a parent or child collection in the backend to enable this type of URL structure.
In these scenarios, migrating from one CMS to another will usually require URLs to be rewritten and redirected. This should be considered seriously when planning and executing a CMS migration.
HTTP > HTTPS
Hypertext Transfer Protocol Secure (HTTPS) is the secure version of HTTP, and ever since Google made it known it would become a positive ranking signal, it has been mass adopted. Google treats the migration from HTTP to HTTPS as a “site move with a URL change,” meaning Google will consider the new URLs to be an entirely new site. Although there are risks associated with this migration, it is regarded as one of the safer types because of how standard they have become within the industry. This involves enabling an SSL certificate for a website and organising permanent redirects from the old HTTP URLs to the new HTTPS URLs.
Our blog on planning for mixed content during HTTPS migrations explains this type of migration in greater detail.
Server migrations
A server migration describes the process of copying and moving essential data from one server to another. This process also involves configuring the new server to replace the old server fully.
Sometimes it might be necessary to switch web hosts when faster response times, increased capacity, or the replacement of ageing infrastructure is desired. Changing web hosts for shorter response times and quicker page load times is the most common reason. In this example, some web host providers use SSD and NVMe storage and are extremely high speed, contributing to incredibly fast server upload/download speeds. As loading time is a top SEO ranking factor, switching to a lightning-fast web host may be highly desired.
Subdomain migrations
Subdomain migrations refer to merging a subdomain (subdomain.example.com) to its parent domain (example.com) and the work this entails. This might be necessary if the subdomain is no longer needed, and the business decides to consolidate the subdomain with its main website.
For example, if a website has its blog sat on a specific subdomain (blog.example.com), a business may decide it’s beneficial to migrate the entire subdomain to the top-level domain and have it sat under a subfolder directory on that domain (example.com/blog). Moving a site’s blog from a subdomain to its top-level domain might improve the flow from its non-blog pages to its blog. Alternatively, a business might want to merge link equity under one primary domain, which could positively impact its rankings.
As subdomains are known to act and function like entirely separate domains, businesses should decide how they want to structure their content and which solution best fits their needs.
Top-level domain
Top-level domain (TLD) migrations refer to changing the TLD of a site (for example, switching a site’s TLD from .com to .org or from .net to .com).
Country Code Top Level Domain (ccTLD) migrations refer to changing a site’s country-specific TLD (for example, changing a site’s TLD from .co.uk to .com). In this example, a business might want to switch from .co.uk to .com if it intends to target a broader audience; outside the business’s particular country/location.
When are CMS migrations necessary?
There are many reasons a business might want or need to change its CMS. In this section, we have outlined three of the most common.
1. Current CMS has outdated or missing features
Transitioning to a new CMS can provide a slew of new features and functionalities that might not be available for your current CMS. One of the more extreme examples is when a business decides to transition to a headless CMS, potentially because of the inherent benefits a headless CMS brings; a decrease in development cost, the time it takes to market a product, and the custom solutions they bring that meet distinct business requirements.
Additionally, a decoupled/headless CMS is highly beneficial for businesses that deal with vast amounts of data due to its ease in delivering content across different marketing channels in various forms and formats.
Better features can also increase staff satisfaction and productivity. If team members participate in the process of migrating a website’s CMS, their input and feedback can result in a platform they are happier working with. This can lead to increased productivity, potentially having a positive impact on a business’s profits.
2. Current CMS lacks future proofing
As the web has progressed, it has become increasingly necessary to use content management systems that offer flexibility and adapt to market needs. For example, non-headless CMSs make it hard to distribute content across multiple channels because of how they silo content and data. As we move towards a more integrated web, with many businesses desiring multi-channel marketing campaigns, these businesses may want to move to a headless CMS because they can control content distribution across wildly different channels and devices.
3. Current CMS lacks support or customisation
Some content management systems can be poor at providing a level of customisation the business needs. As websites are becoming increasingly complex, with businesses’ needs diversifying, businesses may find that their current CMSs lack the support they need to achieve their goals with their website and the content they want to show.
For example, some CMSs are very inflexible with URL structures (as in the earlier Shopify example). Therefore, a business might decide to change its CMS if it believes its current CMS cannot adapt to its needs. More specifically, a brand might want to increase the scope of keywords it currently targets in a competitive market or target long-tail keywords with specific ecommerce landing pages. As Shopify does not allow for product category sub-directories (such as /mens-shoes/trainers/white), the inability to set parent and child categories might be a strong enough reason to move away from this platform.
In general, switching to a different or more modern CMS could mean, in many cases, a more accessible and adaptable platform to work with.
The benefits of a CMS migration
A successful CMS migration can also open new opportunities for your business to succeed online. We’ve outlined some of the biggest rewards here:
Content customisation and features
If your current CMS is creating roadblocks when creating content or creating page templates for your website, switching to a new CMS could be an excellent resolution.
Depending on the CMS of choice, it could offer a broader range of better features and customisation to help improve the quality of your content and user experience, which will have a positive knock-on effect on organic performance – and therefore revenue.
These features and customisations could include:
- better range of elements and content sections to improve UX
- more intuitive user interfaces for ease of use
- content creation assistance (e.g., a drag-and-drop feature)
- full integration of apps, plug-ins, APIs etc.
- can support JavaScript frameworks for more dynamic webpages
- community support through forums, customer service teams etc.
Tightened security
Cybersecurity is a top priority and point of concern for most businesses nowadays.
Protecting all forms of data including personal customer data (personally identifiable information), website data and intellectual property from external attacks is crucial.
Depending on your new CMS of choice, the new platform could offer you a better, tighter level of security against DDOS attacks, hackers and cyberattacks.
For example, CMSs like WordPress, have Web Application Firewalls that provide an added security layer. Others use encryption features and have security teams dedicated to keeping sites using their CMS safe from attacks.
The opportunity to start fresh
If you are using an old CMS and feel like you need more from your platform to keep your website and business moving forward, a new CMS might open new doors for improved web performance and enable you to action your plans.
For example, a new CMS could offer a better and broader range of features (as mentioned previously) that would enable your team to create more dynamic and engaging content and experiences on your site. This could include customisable components to deliver more engaging content on-page such as videos, reviews or dynamically updating product carousels.
These improvements will help your site keep up with the constantly evolving industry and better match any competitors who have much more engaging and interactive sites, which will lead to higher conversion rates.
Faster page speed
It is obvious that site performance is vital for any business wanting to deliver the best experience possible on their websites, and those whose goal it is to convert more customers to gain better profit.
Site speed could significantly improve depending on the existing CMS in question and the new platform you are moving to. This is because old CMSs might not be capable of making the necessary changes to quicken load times (such us optimising JavaScript or improving cache settings) and therefore restrict how fast your site can load.
Furthermore, in some cases, the old CMS might be a slow-running platform in the first instance, meaning users must deal with a frustratingly slow website, which is horrid for user experience and your customer’s perception of your site and brand.
Improved long-term revenue
The main goal of switching to a new CMS is to generate more long-term revenue and improving organic performance will help brands to achieve this goal.
As mentioned previously, the ability to create more unique and engaging content on your website to better meet the intent of your users will help create a more positive experience and, in turn, convert more customers and generate more revenue.
Positive organic results driven by a successful migration project handled by Builtvisible.
CMS migration considerations
Migrations are high-profile, complex programs of change that managed poorly can leave your organic revenue exposed. They have so many moving parts, all of which increase the chances of things going wrong. For this reason, with any migration, preparation is key. Below are some of things you will need to consider and pre-plan before you dive into the nitty gritty.
Project aims and objectives
This is a more obvious consideration, but you should discuss the ‘why’ behind your migration with your team and make sure there is a proper reason to go through this process. Then, you can lay out the project aims and objectives based on this.
You then need to review how quality assurance will be tackled to measure how well the migration is hitting these goals. Having at least two other team members review work completed before implementation will help you identify any errors or problems which might negatively impact the success of the migration and ensure you are successfully moving towards achieving your objectives.
Building your migration team
For a CMS migration to be successful, it needs – at least – both a web developer’s and SEO’s eye to ensure that organic performance is not negatively impacted.
A strong technical team with experienced web developers and SEOs would make the ideal combination for ensuring stability and minimising risk. They will also help with getting essential stakeholders on board with the fact that the importance of organic performance should be at the forefront of priorities.
The SEOs working on the migration should have the relevant technical skills required to complete all the project tasks successfully (more on this later) and be able to effectively get other stakeholders on board with maintaining organic rankings. Ideally, they would also have previous experience with migrations and working with web developers on implementations of SEO recommendations.
You will also need an experienced project manager (this could be the SEO individual if they are experienced enough) to oversee the project and connect all the moving dots from across the various teams collaborating on the project, such as IT, senior management, web developers, marketing managers and any other relevant stakeholders.
Tools, software, and skills
Your team must also be equipped with all the relevant tools and software they need to complete the migration. Some aspects of the project will be automated, but there will be areas where a manual review is required, and some tools are fundamental to completing these tasks.
Performance monitoring will also be vital to understanding how key metrics have been impacted. Details of the tools we recommend using are below and information on how to use these to measure performance is covered later in this guide (see ‘CMS Migration Checklist’ section).
Crawlers
There are a number of options you can use to crawl and store data on the website pre and post-migration. These will be particularly useful when monitoring your redirect. Our favourites include:
We recommend using Screaming Frog as your primary crawler, as it is the cheapest and holds all the utilities required to complete a migration.
Analytics
The usual analytics tools will be fundamental, such as:
- Google Analytics
- Adobe Analytics
- Google Search Console
- Your rank tracker of choice (SEOmonitor, PI Datametrics etc.)
- and any other tools or platforms you use to record organic performance, customer data, sales data etc.
Your team must know how to use these tools effectively to complete the migration, so ensuring your team has the appropriate expertise is essential.
Internal communication and workflows
Migrations can be time consuming which is why it is important to ensure that, for those working on it, there is resource to cover their other priorities outside the migration to ensure these workflows don’t stall.
Putting together a migration roadmap will be extremely beneficial as this will lay out the key milestones of the project and timelines for when its elements are expected to be completed. Furthermore, ensuring you’ve got your ways of working nailed and all contributing parties are familiar with that process and how you manage workflows will be fundamental.
Finally, make sure your ticketing systems are set-up appropriately and are integrated with migration workflows and get all stakeholders on board (if not already) to consolidate all comms into one central hub. One of the tools we use for managing change with enterprise organisations is RACIs
Finding, choosing, and managing external agencies and resources
Getting an SEO agency onboard will provide an extra pair of hands and additional support throughout the process, which will help you mitigate any risk and ensure your goals are achieved. However, finding the right agency to support your project can also be tricky sometimes.
You should look for a team of specialists which have proof of experience managing and delivering successful migrations in the past, so if you are considering hiring an external agency, search for any case studies on their website or ask them if they can share any positive results from previous migration projects with other brands.
It’s important that you meet your account team before hiring them too. Besides their sales representative, make sure you’ve had at least one call with your day to day SEO contact(s) and your account manager within the agency. You can use this call to discuss ways of working and confirm whether they are the right fit for you.
Outside of any SEO agencies, you may also want to consider the possibility of getting additional web developers to help at various stages throughout the migration. The previously mentioned migration roadmap will help you uncover any resourcing gaps in case you need to find the support of a freelance developer in good time.
Content strategy and performance
Part of the migration will be redirecting old content across to the new platform. This provides an opportunity to audit your site’s existing pages and identify poorly performing content that should not be migrated. A few common examples are:
- pages with low word count
- pages with a lack of relevant ranking queries
- pages which show little potential for driving traffic from further optimisation
- lack purpose/provide no value to users
It may be worth conducting a content audit to cull content that meets a combination of these criteria from your site.
This will make stages of the migration more straightforward (less content to redirect) and improve organic rankings (by culling low-quality content, you can enhance the overall quality of your site).
Furthermore, failing to migrate high-value content which drives lots of quality traffic to your site, can be detrimental to your organic performance. A content audit will also highlight your most important content (high traffic-driving, lead-generating content), which should be prioritised as part of the migration. This will help you minimising any risks of traffic – and, therefore, revenue – loses at the back of the migration.
Budgeting
Finally, when planning your finances for this project, remember to consider the additional costs of any external resources mentioned above, such as external agencies or contractor developers, as well as any extra tools and platforms you’ll need to acquire for the successful execution of the project.
The most common CMS migration pain points
As mentioned earlier, there are numerous moving parts that can go wrong during a migration. Below are some of the most common pain points we have experienced from executing CMS migration projects in the past.
Inability to transfer metadata/structured data.
In some instances, your new CMS may restrict the amount of data you can transfer across from the old platform, leaving behind things like metadata (e.g., title tags and meta descriptions) and header tags (H1s, H2s etc.). These are essential elements of your pages from an SEO point of view and, therefore, will have to be rewritten and readded to the new pages as part of the migration.
Transferring structured data tends to be a frequent problem too. Platforms like WordPress generate structured data through a plug-in. Therefore, this data will not be transferred over automatically to the new platform, unless properly configured. For this reason, you’ll need to consider new methods of generating structured data to ensure this data is not lost.
For example, a new review schema component may need to be built within the CMS which would pull in data from, say, TrustPilot, and feed into a review widget on the page. Or you may also need to create a video schema component which enables videos to be embedded on your page’s content.
Differences in the URL structure
When your URL structures are changing (for example, migrating content from /pets/bengals to /pets/cats/bengals), there are a few extra things you need to keep into consideration.
You must keep a backup of all the old URL paths, their historic performance across several key metrics, and the new URLs they are mapped to, as this will be needed when validating the implementation of your redirect map.
Furthermore, this will make performance data comparisons post-migration much more manageable and smoother, helping through the post-launch benchmarking stage (more on benchmarking and redirect mapping later).
Existing plug-ins are not compatible with the new platform
Depending on your current platform and the new CMS you wish to move to, some plug-ins or API connections may perform crucial actions on your site that may not be compatible with the new platform.
This could lead to a loss of functionality or content on page leading to a worse user experience, say if a widget or section of content relies on a plug-in or specific CMS component which is not available as default on your new CMS.
In these cases, alternative solutions will need to be identified and implemented to ensure webpages do not lose essential functions. For example, developers may need to create custom widgets or components to achieve the same level of content and UX as on the old site.
Differences in sitemap and robots.txt handling
CMSs handle things differently and have varying methodologies for service files like sitemaps and robots.txt files.
Moving to a new CMS may mean that you need to set-up entirely new sitemaps and robots.txt files configuration as the data from your current CMS might not be transferable. Be sure to consider this when working on your new CMS set-up as they are fundamental items for managing crawling and indexing of your content.
Common mistakes we see during CMS migrations
1. Indexable staging site
While your new site is under development in the staging environment, you must ensure that Google cannot crawl or index it.
If your staging site becomes indexable, it could duplicate and compete with your live site, cannibalising and harming your rankings. It will also mean users could land an unfinished site with potentially broken features. Platforms like Demandware or Salesforce do this by default, so it’s common to see staging sites on these two platforms appearing in Google SERPs.
The fundamental implementation to stop your staging site from being crawled and indexed is having appropriate directives set up in your robots.txt file to disallow all user agents from crawling all of it, as well as noindex tags on all pages. Furthermore, you could implement an HTTP authentication process to stop any user agents without the necessary credentials from accessing the site.
2. Non-indexable site (post-migration)
This one is a classic mistake which is easy to make considering how busy all parties can be during a migration. Leaving noindex tags in the headers across the site or leaving blocking directives in the robots.txt will stop your key pages from being indexed post-migration. If pages are not in the index, they cannot rank. Therefore, traffic will see considerable drops.
Ensure you remove any robots directives or noindex tags when launching the new site live and add these checks to your checklist to ensure they don’t get missed.
You can check the status of URLs in Screaming Frog by viewing the ‘Indexability’ and ‘Indexability Status’ columns:
3. Forgetting to remove old sitemaps
Forgetting to remove your old sitemaps from Google Search Console will cause Google to continue to crawl old URLs, wasting valuable crawl budget.
You can remove old sitemaps and add new ones within the ‘Sitemaps’ section of GSC:
Whilst you need to remove any old sitemaps from GSC post-migration, it’s recommended to wait a few weeks after the new site is live, to allow Google to still crawl all the old pages and recognise the redirects before you remove the old sitemaps.
4. Implementing mass redirects to the home page
Migrations that are done without considering SEO and the impact on organic traffic can sometimes end with all redirects pointing to the new home page. Unbelievably, we’ve also seen this happen numerous times over the years.
This is a massive no-no as, with these redirects, you are telling search engines that the new location for all of this redirected content is now the homepage, which essentially translates into all the relevancy signals associated with the old content being lost.
For this reason, it’s important that you redirect your old pages to the most similar page on the new site, which will prevent significant ranking loses.
5. Migrating your CMS on a Friday
Migrating your site on the last working day of the week is never a clever idea and, whilst this might sound like common sense, it’s another mistake we’ve seen quite a few times.
If anything goes wrong with the migration, no one will be at hand to roll back previous implementations and resolve the issues. They will linger over the weekend and will only be picked up when the next week commences. Unfortunately, this could have considerable negative influences on organic performance.
We recommend migrating your site early in the week so that any issues can be rectified straight away to protect your positions on the SERPs and that there is plenty of time in case a roll back is needed.
6. Migrating during peak seasons.
On a similar note to the previous point, migrating your site during a season of peak demand and sales will raise unnecessary risks to your business and its profits.
For example, it would be unwise for an ecommerce retail store to plan the migration stage of the project over the autumn period, which includes Black Friday.
To minimise these risks, it is always best, if possible, to migrate your site during quieter seasons which, if technical issues arise, will have less of an impact on performance.
Migrating to JavaScript Frameworks / Headless CMS Considerations
What is a JS framework?
In brief, JavaScript frameworks are a collection of libraries containing code written in JavaScript. Each JavaScript framework offers pre-built codes for different areas and different purposes in software development. They allow programmers to use the most up-to-date JavaScript features and tools without going through the arduous task of coding them independently.
Furthermore, they allow developers to build and scale interactive web applications quickly, which is a big deal, as most websites heavily use JavaScript to add interactivity and improve user experience. This type of frameworks is becoming increasingly used; however, they can kill a website’s SEO if implemented incorrectly. This is because, even if Google has gotten better and better at crawling JavaScript recently, there are still limitations.
What is a headless CMS?
A headless CMS is a content management system that separates where content is stored from where it is shown. In this sense, where the content is stored is called the “body”, and where the content is shown is called the “head”. This differs from a traditional CMS, which usually has one monolithic way of displaying content (usually a webpage). Headless CMSs, on the other hand, offer complete flexibility in how websites display content to users. This is done through an API that acts as a mediator between the Data Layer and the final rendering.
Why would you want to migrate to a Headless CMS?
Headless CMSs offer increased security. Although monolithic CMSs are simple and convenient, the trade-off with this is a higher security risk due to the number of out-of-the-box plugins they usually require, which are highly susceptible to hacking attempts. For example, plugins are always necessary when using a CMS like WordPress – the most popular CMS in the world. These plugins are extremely common to function as back doors to the platforms they have been installed on, especially if they are outdated, which is also quite common.
Additionally, the fact that the content repository is separate from the front-end with a headless CMS offers a hugely valuable benefit; if somehow the content in the backend were accessed and edited by hackers, the separation from the front-end would keep these changes from being displayed on the website.
Migrating to a JavaScript framework adds a layer of complexity to the already complicated process of migrating a site’s CMS.
Migrations alone can be challenging projects. There are many complex details to keep in mind when performing migrations; ensuring redirects have been appropriately mapped, maintaining good website architecture, eliminating errors, and correctly setting up robots.txt and XML sitemaps, to name a few.
And migrating to a JavaScript framework adds another layer of complexity to the already complicated migration process. This is because, when migrating to a JavaScript framework, project managers must ensure the new website using a JavaScript framework is SEO friendly. More specifically, those involved in this kind of migration must ensure there are no issues with how the new pages are being rendered and that search engines can view all necessary content and links effectively. As mentioned earlier, Google Google and other search engines have significantly improved their JavaScript rendering capabilities, however, there are still some crucial limitations. Therefore, webmasters must ensure that their websites are serving pre-rendered or server-rendered content to these search engines.
Your CMS Migration Checklist
Now that we’ve gone through some of the benefits, risks, and considerations to be considered when migrating your site, it’s time to go through the steps needed to execute a successful migration. We typically approach migration projects in three phases:
- Pre-migration planning and optimisation
- Testing
- Post-launch
The below dives into these 3 stages in more detail and includes a checklist of what must be completed during each phase to ensure you are set-up for success.
1. Pre-migration planning and optimisation
1.1 Get stakeholder buy-in
The first thing you need to do is ensuring all relevant internal and external stakeholders are totally onboard with the project. This means that they’ll need to be familiar with the migration objectives, roadmap and methodologies used to complete the project, and that they are embedded in all internal communications.
This will help you overcome any potential roadblocks (and frustrations), such as lack of resources, missing tools, or data, etc. and will contribute to a smoother implementation of the migration.
1.2 Run checks and technical audits
A migration is a fantastic opportunity to improve your site’s technical health (which will help you improve your organic performance). Therefore, before conducting a migration, you should evaluate your current site’s technical health, so that you can make the necessary improvements as part of the migration process.
1.3 URL data collection & redirect mapping
The redirect mapping is one of the most crucial elements of a migration. Ensuring high-value URLs are mapped (and redirected to) the correct location on the new site is crucial for maintaining a hold on your link equity/PageRank. Losing this could mean huge drops in visibility for the new site and is often one of the main causes for traffic drops.
As mentioned earlier, redirecting the old URLs to their new version (or the most relevant page as an alternative), will also ensure that all relevancy signals are passed through. Failing to do this will result in relevancy signals – and, therefore, organic rankings – being lost.
Check out our guide on redirect mapping for successful migrations to learn the best approaches for mapping legacy pages to new URLs.
1.4 Performance benchmarking
Before conducting a migration, is important that you benchmark the current site performance against key business metrics, so that you can perform some comparisons after implementation and ensure performance doesn’t drop at the back of the migration.
1.5 CMS functionality review
As you are planning to move to a new CMS, you need to consider what functionalities and capabilities the new platform has vs your current one, to ensure some minimum-level requirements can still be met.
At this stage, you should conduct a comprehensive review of what your current CMS offers to benchmark against the new platform and identify any holes you’ll need to build functionalities for.
1.6 Conduct a content audit
An audit should also be performed to determine content that should be either transferred to the new CMS, consolidated / merged with other pieces, or removed.
Ideally, you’d have performed a content strategy and audit within the last 3/6 months, which you could use as a base and refresh (to ensure this is up to date). However, if you haven’t, you’ll need to perform one from scratch.
1.7 Ensure the new site is secure
Before migrating to your new platform, checks should be run to guarantee that the new site is secure, and that necessary consumer data is not at risk.
Enforcing multi-layered access levels by restricting permission to certain site areas or ensuring your new site has an SSL and the uses HTTPs are fundamentals for website security. You should also ensure that the web host you have chosen provides sufficient security for your needs.
From there, you can update your privacy and cookie policies and provide the relevant information to your users on the new site.
1.8 Automate the process to improve efficiency and reduce the risk of human errors
Review the tasks you have laid out ahead of you and identify those that could be automated to save you time and resources.
For example, instead of manually copying substancial amounts of content on your site, your developers could create a custom script which collates all the existing content from your current CMS platform and transfers it to the new CMS via API. This would save you lots of time and help you avoid potential mistakes being made due to a human error.
2. During Migration Testing
2.1 Test fixes and updates on a staging environment
You should test – and validate – all your changes on your staging environment before going live to mitigate any risks of harming organic performance of the new site. Make sure everything is functioning as it should and, if you identify any flaws, make sure the necessary changes are made in staging and checked again before going live.
2.2 Keep a close eye on organic performance metrics
Use Google Search Console to monitor impressions and average position across the site. Use the benchmarks you set pre-migration as a comparison to see how your actual data compares to your predictions and forecasts.
Also, keep an eye on the ‘Index’ tab in GSC (previously called ‘Coverage’) to monitor the indexability status of sets of pages; this will highlight any potential problems with the migration if important pages cannot be indexed.
Google Analytics will also come in handy to measure the organic traffic to key pages. Again, measure this against your benchmarks set pre-migration for comparisons. You can also monitor the live traffic level in real-time, which will allow you to move quicker if any problems arise.
2.3 Have your ‘plan b’ to hand
If you notice any significant drops in performance whilst running your tests, be prepared to roll back recent changes which might have contributed to the problem and work on a solution as quickly as possible to ensure the progress of the migration is not delayed for too long.
Ensuring you have backup data (e.g., content backups) for situations like this will be extremely useful here.
3. Post-launch
3.1 Audit your live environment thoroughly
Once your migration is complete, further robust testing and monitoring of the live environment will be required to measure performance over the following days/weeks.
This is a crucial stage of the migration as it will help you uncover any potential issues overseen at previous stages of the project, which will contribute to performance drops.
You need to do this immediately after launch, to ensure you fix any potential problems before performance starts to sink.
3.2 Analyse and monitor organic performance
Now it’s time to get your benchmarking reports and start comparing your new site’s performance against these. Some of the questions you should answer are:
- is organic visibility, rankings and traffic maintaining / improving / declining its trajectory?
- which pages and keywords are contributing to this trend?
- have conversions and revenue continued their expected trend
More details on how to investigate further if you notice any performance declines are included in this blog post.
3.3 Check for old URLs in the index
You can also use search operators to run some site: searches, as shown below, and see if any legacy URLs are indexed. This could indicate that something has gone wrong with redirects:
For more information on search operators like this, check out Ahrefs’ complete guide.
Tip: repeat this process to check if there are any staging URLs indexed too.
3.4 Monitor and measure site speed and mobile performance
Run the new site through Page Speed Insights to analyse how fast it loads for mobile users. Depending on the type of migration, Crux data might be unavailable as it collates data from the previous 28 days to calculate your metrics. However, lab data (“data based on a simulated load of a page on a single device and fixed set of network conditions”, according to Google) will always be available.
Look out for any extremely long load times for ‘First paint’ or ‘Largest contentful paint’ and any delays in ‘Server response times’ or ‘Time to interactive’:
Any bad scores for these metrics will indicate that the site is not performing at its best for mobile users.
Final thoughts
CMS migrations are incredibly complex projects which can eat away at internal resources but, with the right planning, structured phased approach with SEO in mind, can provide a wealth of benefits for your business in the long term.
However, a bad execution will ruin a good decision, so it’s important that you don’t leave anything to chance and involve your SEO team or agency at early-stage planning. This will give you a rock-solid business case, quantified risk vs opportunity and a partner to lean on when managing your project.
For more insight into how we tackle migrations, check out our approach to site migrations and how we can help you deliver a smooth and successful transition that preservers and improves organic performance. Get in touch if you are interested!