CMS Migration Guide: A Checklist by Mr.Lukash

Learn how to migrate from one CMS to another. CMS Migration Guide based on Pavlo Lukash’s experience and lessons learned.

Website migration is a serious step for any business where improper preparation may cause a company even millions of losses in web visits, revenue, and/or trust. It is hard to predict where the bugs come from as the website or CMS nowadays is not anymore a simple-1-page HTML file in your root catalog, it is complex in design and structure and dynamic machine to convert visitors to customers, build relationships, serve your client needs and support marketing.

So, it is crucial to ensure that you are well-prepared and have a plan. And if you even have one, do not forget to enrich it with good advice from here…, and make the migration process SEO-friendly.

I promise, that the above will be the only ‘water’ you read here, the rest is very short and just straight to the point. So, keep on reading.

1. Break the process to smaller pieces

CMS/Website is a big cake and taking it into pieces will bring clarity of what is it made of. So, what are the components you may ask:

• Domain names, DNS settings, Alias (Domain aliases are domains that you own, but which do not contain any content. Instead, they point to the contents of another domain or subdomain on your account. This is useful, for example, to hold a domain that you will later sell, or to redirect traffic to another domain.) I am sure the company has a lot of those.
• Server part (hosting, CDNs, files and media storage, cron jobs, databases, rewrite rules, file storage, sFTP)
• URLs, including backlinks, redirects (be careful with 301/302 redirects as those have to be migrated as well), robots.txt, htaccess rules etc.
• Content (Internal, external *iframes, resources loaded from other places, not stored on local server) such as images, icons, videos, banners, fonts. Everything you see and not see in the browser (image alt tags, image descriptions, and other markup data).
• Analytics, tracking codes (FB pixel, Google Tag manager, Google Analytics, Pardot, HubSpot, Salesforce etc tracking codes, scripts)
• …

It requires a lot of work upfront but also produces huge savings of time and money in the long run, provided the SEO (URLs, content, redirects) and marketing parts are done correctly. And that is exactly what I will be covering here.

!One thing to note here about SEO: you might see a temporary decrease in traffic even if everything has been done correctly. The reason is that Google needs time to re-evaluate your new site, and the more structural changes have been made, the longer it can take. But this traffic decrease should be analytical, measurable, and decision driven, so please record data before and compare! After migration.

There are many types of migrations, including:

• Moving from HTTP to HTTPS (hardcoded links in texts might have an issue after copying/pasting)
• Moving from a subdomain to a subfolder or vice versa (jobs.domain.com to domain.com/jobs)
• Moving from one domain to another

2. The Main Issues You Might Face During a CMS Migration

It is obvious that the old CMS and the new CMS features are not matching as Lego blocks. Here are some possible issues you might discover while switching your CMS:

• Inability to Keep the Old URLs Structure
  Example: Shop category name is included in the product URL by default. (website/furniture/armchair1.html) So if your new product URLs don’t include the category path, you will need to use some customization or redirect to achieve SEO perfection.

• Different Templates or Rules for Generating Meta Tags and H1 Tags
  Example: HubSpot doesn’t allow having different H1 and title tags on a page (though they seem to be in the process of changing it).

• Different Approach to the Service Files (txt, XML sitemap)
  Example: Some CMSes does not allow editing the robots.txt and XML sitemap. So if you are migrating to it, you should account for that.

• Structured Data
  Example: If you are migrating from old CMS where you use structured data, find similar approach  that will work for your target CMS.

Schema.org is everything!

• Flexibility (canonical links, meta robots, meta description, etc.)
• Analytics tagging

NB!!!: Tracking codes are often overlooked. Before the migration starts, you should make a list of all the tracking codes and customizations to transfer them to the new CMS.

3. Good advice is pure gold!

A. Run a Crawl

Before you even start planning the migration, you need to understand the scope — are there 100, 1,000, or 10,000 URLs? You also want to find any technical issues which should not be transferred to the new CMS. For example, you might find pages with self-referencing canonicals, while these canonicals should point to other URLs instead.

After the crawl, you will have a list of the website(s) pages. I always recommend using a few sources to get a full list, including:

• Crawl Data – Like the Screaming frog, Semrush, Ahrefs or similar..
• Google Search Console pages
• Google Analytics pages
• Your XML sitemap(s) from the old CMS

For example, you can export crawled pages from SEMrush Site Audit:

Export all URLs from each tool, combine them into one document and remove duplicates.

Additionally, before making any changes to the current website, you should create a backup (or make sure that it is done on the dev side). Of course, after the CMS migration, the folders’ structure on the server will look different. But you will at least have raw data and content you can go back to if something goes wrong or gets deleted.

The outcome of the A step:

• You have a comprehensive list of all website URLs.
• You have a list of the technical SEO issues you want to fix during the migration to another CMS.
• A backup of the current website.

B. Analyze CMS Features

Now it is time to see how the features of your current CMS are translated into the features of the new CMS. Make a list of things to take into account while migrating. These will be absolutely important SEO aspects that you want to have control over as much as possible.

They include:

• URL Structure – You want to leave the same structure if that is possible. But if not, you should know it at this point before creating the redirection map.
• Meta Information – You want to leave the same tags or mimic the meta tags templates. If it is not possible, create new templates that will be supported by the CMS you are migrating to.
• Website Architecture – Make sure that nothing will be lost during the migration process, e.g., the breadcrumbs will stay, the main navigation will have the same categories, etc.
• Canonical Tags and Meta-robots Directives – The new CMS should give the option to change these settings on a page level.
• txt and XML sitemap.
• Structured data.
• Hreflang (for International websites).

Any important custom features – Automatic rules for creating new pages, redirecting old pages, etc. For example, if you are migrating an online store, and the old CMS has a feature to automatically redirect a discontinued product to the category page, your migration plan should include it as well.

This step is complex and requires lots of research and cross-team communication, but it is the backbone of the whole migration process.

The Outcome of the B Step:

A list of the most important SEO features and ideally an indication of whether each feature is available in the new CMS. The more you know, at this point, the better.

Note: If the CMS you are migrating to is custom-built, you will most likely have no information on the functionality available there. You still need a list of the features which are absolutely necessary for SEO so that they can be created or added to the custom system.

 

C. Indicate the URLs to Redirect

By this step, you already have a list of all the website pages as well as know if any changes in the URL structure will be required. So now it is time to create a URL map.

Keep the map simple. I usually include just 3 columns:

Old URL, Action, and Final URL

Domain.com/products/hydrogen                   do nothing           Domain.com/products/hydrogen

Domain.com/products/asu                               redirect                Domain.com/air-separation-unit/

Domain.com old pages, not relevant             do not migrate  

Then create an additional map that will have only the URLs that need to be redirected. This redirect map is for the developers.

The reason why I prefer having 2 maps is simple: I want to make sure that each URL is handled properly. If you create only the redirect map, you might miss that the other URLs return 404s. So I keep the map with all pages for myself and send the redirect map to the developers.

The outcome of the I step:

• A map of all the URLs with an indication of the action.
  • URLs for pages, files, images (with Alt tags)
• A redirect map for developers.

 

D. Note Down User Stories and Acceptance Criteria

When it comes to complicated technical things like switching a content management system, it is important to communicate your requirements and recommendations properly (and even overcommunicate).

That is where user stories come in. A user story states the outcome you want to achieve. It follows this structure:

As a {type of user} I want {outcome} so that {the reason}

For example:

As an SEO, I want product URLs to be the same even if users go to the product page from different categories so that we don’t have duplicate product pages.

Each user story should have acceptance criteria. They clarify the outcome you want to achieve. Here is an example of acceptance criteria for the above user story (for online shop):

• Product pages are found within the /products/ sub-folder.
• Product pages are not found inside of any /categories/ sub-folders.
• Product pages contain canonical tags that point to themselves.

The link to products that are part of multiple categories is the same URL no matter what category it is in.

NB! Do not forget the internal links point to the canonical versions of the product URLs. Often sitemap is created without analyzing links hidden in texts pointing to some products. Internal linking is the KEY! To succeed in SEO and should not be forgotten or you have a 404 and a huge drop in SEO ranking and user experience!

The outcome of the D step:

You have user stories and acceptance criteria for each user story ready to be uploaded to the task management system (e.g., JIRA).

 

4. TEST!!! CHECK!!! TEST!!! CHECK AGAIN!!! (No screaming 😊 )

It is the most important of all the processes. We do not allow any content to be changed without proper checking of: URL, content, alt tags, tracking code, breadcrumbs, schema markup, h1, title, meta descriptions etc are present.

You should have a checklist for all above available for each user who will be migrating content automatically or manually! All users responsible for whatever content and page migration should complete the checklist for EVERY SINGLE page of a website.

There will most likely be a few rounds of testing as after each issue is fixed; you will need to re-test it. Once it is completed, the test website should be ready to go live.

Once It is Done, it is never Done 😊

After the website goes live, it is time to make some final but crucial checks.

Check if the redirects in your redirect map are implemented correctly by another user!

You can do it using the list mode in Screaming Frog:

• Check your robots.txt to make sure the website is allowed for crawling.
• Check meta robots to make sure the indexing is allowed.
• Check if the tracking codes are installed.
• Add yours..

The outcome of the final step:

You are sure that all the information was transferred correctly, and the website on the new CMS is ‘SEO healthy’.

Need help with CMS Migration? Click here