CMS migration & URL continuity

Enterprise CMS Migration and URL Continuity

A CMS migration is usually approved for good reasons — an unsupported platform, editors who cannot work without developers, several sites that should share one system. It goes wrong in quieter ways: addresses that stop resolving, metadata left behind, language versions that lose their pairing, documents nobody re-uploaded. This page describes how we move enterprise websites to a new CMS without treating those details as an afterthought.

Short answer

MadeByCat moves enterprise websites to new CMS platforms through a controlled process designed to preserve existing content, URL value and search visibility. Scope includes content inventory and modelling, migration of content, media and documents, old-to-new URL mapping, 301 redirects, metadata and multilingual continuity, QA, a controlled launch and post-launch crawl checks. No migration can guarantee unchanged traffic; the process is built to keep avoidable losses out.

01

Choosing a migration partner: evidence before a launch date

This is for marketing, communications and IT teams moving an unsupported or limiting CMS while retaining useful content and existing addresses. Ask the partner to demonstrate its inventory, field mapping and redirect validation method—not only the new interface. A published CMS case proves its recorded platform scope; it does not prove an unreported traffic outcome or a complete URL migration.

  • Agree who exports content, approves keep/merge/retire decisions and owns the redirect rules in the hosting layer.
  • Review a sample migration on staging: content, documents, links, metadata, language pairing and editorial permissions.
  • Write acceptance and rollback conditions before cut-over; record unresolved items and who will fix them.
  • Keep legal approval, bulk rewriting and infrastructure changes outside scope unless explicitly commissioned.
02

When a CMS migration is the right move

Migration is a means, not a goal. It makes sense when the current platform blocks the business rather than merely looking old. Where the existing CMS can be upgraded or reorganised, we say so before recommending a move.

  • The platform or its key extensions are no longer maintained, or security updates have become hard to apply.
  • Editors depend on developers for routine pages, and the content model no longer matches how the organisation publishes.
  • Several sites or brands run on separate systems that should share components, standards and operations.
  • Multilingual content is maintained by copying pages instead of through a language-aware structure.
  • A redesign is planned anyway and rebuilding templates on the old platform would cost more than moving.
03

Content and URL inventory

Every migration starts with a record of what exists today. The inventory covers pages, files and the addresses they live at, so that each item has a decision before anything moves.

  • Crawl of the live site plus CMS export: pages, documents, media, language versions and their current URLs.
  • Keep, rewrite, merge or retire decision for each item, owned by a named content owner.
  • Pages that carry search value, inbound links or campaign traffic flagged for priority handling.
  • Existing redirects recorded, so old chains are resolved rather than extended.
04

Target content model

Content is not moved into a copy of the old structure. We define content types, fields, relations and reusable components in the new CMS first, then map the current fields onto them. That is where editorial roles, language handling and structured data are designed in, rather than added after launch.

05

Migrating content, media and documents

Migration is run as editorial work with engineering support: scripted where volume and structure allow, manual where judgement is needed. Media and documents move with their alternative text, captions and file names reviewed, and document links are checked as carefully as page links.

06

URL mapping and the 301 redirect plan

Each old address is mapped to its new destination before launch. Unchanged URLs stay unchanged where the new platform allows it; moved or consolidated pages receive a permanent 301 redirect to the closest equivalent; retired content without an equivalent is handled deliberately rather than sent to the homepage by default.

  • Old-to-new URL map reviewed by the client’s content and SEO owners.
  • One-hop 301 redirects, without chains or loops.
  • Document and media URLs included in the map, not only HTML pages.
  • Redirect rules tested on staging against the full map before go-live.
07

Canonical, hreflang, metadata and schema continuity

Search engines and AI answer engines read more than the visible page. Titles, descriptions, canonical tags, language alternates (hreflang), structured data and sitemap entries are carried over or rebuilt per template, so each page keeps describing itself correctly at its new address and each language version still points to its pair.

08

Roles, draft, preview and approval in the new CMS

A migration is also the moment to fix how publishing works. Author, reviewer and publisher roles, draft and preview, and approval steps are configured before editors start working in the new system. The day-to-day editorial workflow across several sites and teams is covered on its own page.

09

SEO, accessibility and performance QA before launch

Before go-live, the migrated site is checked against the inventory: page structure and headings, internal links, redirects, metadata, language pairing, structured data, alternative text, keyboard and contrast checks on key templates, and general performance tests on representative pages.

10

Controlled launch and post-launch crawl checks

Launch follows a written cut-over plan with a content freeze window, a rollback path and named owners. After launch we crawl the live site again, compare it with the inventory and redirect map, resubmit sitemaps and review search console coverage and error reports with the client, fixing gaps in the first weeks rather than waiting for them to surface.

We do not promise zero traffic loss. What the process can do is remove the avoidable causes — broken addresses, missing metadata, unpaired languages, lost documents — and make the remaining effects visible early.

11

Scope, outside scope and client inputs

The split is agreed before work starts and written into the project plan.

  • Included — inventory, content model, migration, URL map and redirect plan, metadata and multilingual continuity, QA, launch support and post-launch crawl checks.
  • Outside the default scope — hosting and infrastructure contracts, rewriting content at scale, legal review of content, and changes to third-party systems.
  • Client inputs — access to the current CMS and analytics, named content owners for keep/retire decisions, approval of the URL map, and final publishing sign-off.
12

How to move to a new CMS without losing content or Google URLs

Treat the migration as an inventory and mapping exercise before it is a build. Every page, document and media file is listed, every old URL gets a decided destination, and the launch is checked against that plan. No migration can promise that nothing changes; the aim is that nothing valuable is lost by accident.

  • Content inventory — pages, documents, media and owners, with a keep, merge or retire decision for each.
  • Old-to-new URL mapping — one row per old URL, approved by the content owner before build.
  • 301 redirects — implemented from the approved map, avoiding chains and redirects to the homepage.
  • Migration validation — sampled and scripted checks that content, metadata and links arrived intact.
  • Editor roles, approvals and preview — set up in the new CMS before editors take over.
  • Multilingual content — language versions migrated as pairs, with canonical and hreflang kept consistent.
  • Launch monitoring — crawl, redirect and error checks after go-live, with fixes prioritised.
13

Published migration evidence

Çalık Holding: roughly 22 previously separate interfaces and web properties are in transformation scope; 17 have been migrated to date onto MadeByCat XMS with centralised content entry and operations, and the migration is still in progress. Global Ports Holding: port sites operate on a shared master-site platform with per-port localised content and CMS governance. The case pages describe scope and delivery; they do not publish traffic figures, and none are claimed here.

Evidence and related case studies

Frequently asked questions

Can a published CMS case prove that all URLs and traffic were preserved?
No. A case supports only the scope and results it explicitly records. For your migration, request an approved URL map, redirect test results, content validation and post-launch crawl checks; traffic continuity is not guaranteed.
Will we lose search traffic when we change CMS?
Some movement is possible with any migration, and nobody can honestly guarantee zero change. URL mapping, one-hop 301 redirects, metadata and hreflang continuity and post-launch crawl checks are there to remove the avoidable causes of loss.
Can we keep our existing URLs?
Where the new platform allows it, yes — unchanged URLs are the safest option. Where addresses must change, each old URL is mapped to its closest new equivalent with a permanent redirect.
Do you migrate PDFs, images and other documents too?
Yes. Documents and media are part of the inventory and the URL map, because they often carry inbound links and search value of their own.
Do we have to move to MadeByCat XMS?
No. We migrate to the CMS that fits the organisation. MadeByCat XMS is one option, used where its multi-site and operations model is the right fit.
What happens after launch?
We crawl the live site, compare it with the inventory and redirect map, review search console reports with you and fix gaps. Ongoing care can continue under managed website services.

Planning a CMS migration?

Tell us which platform you are leaving, how many sites and languages are involved and which pages matter most. We will outline the inventory, mapping and launch plan.

Contact us→