A pre-migration checklist for non-technical teams

A CMS migration is usually thought of as a technical project, and the technical part matters. But a surprising share of what decides whether it goes smoothly is settled on the client side, before any content moves, in decisions only the business can make. When those decisions are made well and written down, the technical work has firm ground to stand on. When they are skipped, the same questions surface later, at the worst possible time, and the project pays for it.

This is the checklist for the non-technical team. None of it requires you to understand the code. All of it is yours to own. If you are new to working with a delivery partner at all, our non-technical guide to working with a dev agency covers the wider ground; this is the migration-specific version.

The CMS migration checklist

The checklist runs in five stages, and each one turns on a decision only your side can make.

Before you start, get clear on the why

• Write down what you are trying to achieve. “Move to a new CMS” is not a goal. “Let the marketing team publish without waiting on developers,” or “get our content into a form our new app can use,” is. The goal shapes every later decision, and a project without one tends to migrate everything, change nothing, and wonder why it did not help.
• Name who this is for. The people who will use the new system every day should have a voice before the shape is fixed, not after launch when it is too late to change. List them now.

Know what you have

• Inventory your content. Someone on your side should be able to say roughly how much content exists and of what kinds: pages, articles, products, and how they relate. You do not need a perfect count, but you need enough to size the work honestly. A plan that cannot say how much it is moving cannot say what it will cost. On WordPress the shapes worth counting are the post types and the custom fields behind them, and migrating from WordPress to Payload sets out what each of those becomes on the other side.
• Decide what not to bring. A migration is the best opportunity you will get to leave dead content behind. Go through the inventory and mark what is duplicated, abandoned, or no longer read. This is a business decision, and it is yours to make rather than one to leave to the developers by default.
• List what connects to your CMS. Forms, analytics, a CRM, an email tool, a search service. Anything wired into the current system has to be accounted for in the new one. Write down what you know is connected, even if you are unsure how.

Protect what you already have

• Flag your important URLs. Every address that people bookmark, that other sites link to, or that ranks in search is an asset. When URLs change, those need to be redirected, and the work starts before anything moves. You do not have to build the redirect map, but you should make sure your partner treats it as essential. We explained why in why we track redirects from day one.
• Note anything with a deadline. A vendor end-of-support date, a contract renewal, a campaign, or a seasonal peak. If the platform you are leaving is approaching end of life, check where it stands on our CMS end-of-life matrix, because that date changes the urgency of the whole project.

Agree how the project will run

• Decide who signs off. Every project needs one person or a clear path that can approve scope and make decisions. Working out who that is before the first sprint prevents the most common source of delay, which is a project waiting on a decision nobody has the authority to make.
• Insist that “done” is defined in writing. Ask that acceptance criteria sit alongside each piece of the work, so whether something is finished is a question with an answer both sides agreed in advance, rather than one argued about at the end.
• Get scope, price, and date in writing before work starts. With the out-of-scope items named explicitly. A migration quoted loosely against a vague brief tends to expand as the real work surfaces, and the expansion is billed to you. Fixed scope against a fixed price is what keeps the rest of the promise honest.

Plan the landing

• Ask for a verification step before cutover. There should be an explicit point where the migrated content is checked against the original before the old system is switched off. Make sure that step exists in the plan.
• Ask what happens if something goes wrong. A good plan includes how quickly the old system can be restored and who makes that call. You are not expecting to need it, but a team that has planned for it has usually planned for the rest of the risk too.
• Pick a quiet window for the switch. Avoid cutting over the day before a campaign, a board meeting, or a seasonal peak. Give the change room to settle.

What to insist on from your partner

Everything above is yours to own. Two things are theirs, and both are worth asking about before you sign.

• Treat it as a data project. Content in the old system is stored in that system’s structure, and the new one has its own. The work in the middle is turning one into the other without losing anything, and it is where most of the effort sits. A vendor who describes the move as a quick export and import has skipped that part. Ask how they plan to handle the content that does not map cleanly.
• Ask whether a staged move is possible. For a large organisation with many teams on one platform, the instinct is to halt everything, migrate, and restart. That is rarely necessary and always expensive in lost momentum. There are patterns for moving teams across while both systems keep running, which we covered in moving teams off a legacy stack without a freeze.

A CMS migration project plan you can adapt

The checklist above prepares your side. This section shows the project those preparations feed into, so you can see where each decision lands and what stalls when one is missing.

The example is illustrative. It describes a membership organisation with roughly 1,200 pages, three editorial teams, an events system and a member database, leaving a CMS whose current version loses support the following year. No part of it is a client project and no result is claimed for it.

Set provisional dates after discovery, using the content inventory, connected systems, editorial capacity and support deadline. The example leaves durations open for you to fill in. Each stage has evidence to check before moving on; an approaching date does not remove an unmet launch condition.

Stage	Who owns it	Starts when	Evidence needed to move on
Discovery	Your sign-off owner, with the partner’s lead	The goal is written down and the sign-off path is named	An accepted content inventory, connected-system list, URL inventory, retention decisions and agreed launch and rollback criteria
Content mapping	Your editorial lead, with the partner’s technical lead	Discovery evidence is accepted and the decision on what to leave behind is made	Every content type has a destination shape, exceptions have named decisions, and publishing roles and approvals are agreed
Trial migration	The partner’s technical lead	The mapping document is signed off	A representative sample moved end to end, and a written list of what did not map cleanly
Verification	Your editorial lead accepts the content; the partner’s technical lead runs the checks	Trial exceptions are resolved and the full in-scope migration is rehearsed in a test environment	Content and asset counts reconciled, representative pages checked, links and redirects tested, publishing rights and integrations exercised, and failures fixed or accepted in writing
Cutover	Your sign-off owner decides, the partner executes	Verification is accepted, the rollback procedure is rehearsed, and the final content-sync or publishing-freeze window is agreed	Changes since the rehearsal are reconciled; the live site, redirects, publishing and integrations pass the agreed checks
Settling in	Your editorial lead, with the partner on support	Cutover checks pass and monitoring is active	The team completes its publishing tasks, outstanding issues have owners, and support handover is accepted; search and analytics observation continues on its own dated schedule

Decisions your organisation owns

Deciding what content to leave behind, agreeing who holds publishing rights in the new system, accepting the mapping exceptions, and making the cutover call all sit with your organisation. A partner can prepare the evidence for each one and cannot make any of them for you. This is why the checklist above comes first: a project that reaches content mapping without a decision on what to leave behind stops there, and the stop is expensive because a team is already on the work.

Somebody has to review the mapping exceptions and represent each editorial team. Use the trial migration to estimate that review load, then reserve time for it. Page count alone will not tell you how many exceptions need a decision.

When a stage blocks: verification finds broken internal links

The trial has proved that the mapping works on a representative sample. Verification now checks the full rehearsal, including content that the sample did not contain.

In this example, the editorial team finds that internal links inside body content were stored as full addresses pointing at a retiring hostname. About one page in sixteen carries at least one. Those links will fail if the hostname is withdrawn without redirects. This example assumes that address changes as part of the project; a CMS move can also keep the same public URLs.

The size of the fix, and of any delay, is unknown until the links are counted. Verification cannot close in the meantime, so the cutover gate is unmet.

Three people carry different parts of the decision. The partner’s technical lead reports the count and what each option costs. Your editorial lead says which of those pages carry traffic or inbound links. Your sign-off owner picks from these options:

• Rewrite the links before cutover, and let the date move.
• Cut over on the planned date with tested redirects from the retiring hostname, and rewrite afterwards. Confirm who controls its DNS and certificate, who maintains the redirects and whether any hosting contract must be extended. Keeping redirects reachable does not always require keeping the old CMS running.
• Prioritise pages with traffic or inbound links and record the remaining exceptions for explicit approval. Each deferred item needs an assessed user impact, an owner and a deadline. Essential member journeys and retained records still have to meet the agreed acceptance criteria.

The third option needs traffic evidence alongside the editorial team’s knowledge of essential content. A page with no recorded visits can still contain a required policy or support a member’s next step. The URL inventory makes those decisions traceable.

For this example, the sign-off owner chooses to rewrite before cutover. The technical lead reruns the full migration and link check; the editorial lead verifies affected member journeys and accepts the result. The owner confirms a revised launch date after the final content-sync plan and rollback rehearsal are ready. Verification has a recorded resolution, so the cutover decision can proceed.

Go/no-go and rollback are different questions. Go/no-go is the cutover decision above, made on verification evidence before the switch. Rollback responds to an agreed failure after the switch. Name who can trigger it, define the trigger and rehearse restoration. Keep the old system restorable for the agreed window, and state how content edits, event bookings and member-data writes made after cutover will be retained or reconciled. A backup taken before launch does not contain those later changes. Record the end of the rollback window in the plan.

Adapting it to your project

The stage names hold at most sizes; the owners and the gates are what you change. One editorial team instead of three collapses discovery and mapping into a shorter conversation with the same evidence. A regulated retention obligation adds a stage before mapping, where legal confirms what has to remain addressable. An estate with several teams publishing to one platform usually needs the trial migration run per team, and each team verifies its own content.

The point of doing this first

None of the checklist items is technical, and that is the point. They are the decisions and the knowledge that only your side holds, and getting them straight before the build starts is what lets the build start from certainty rather than from guesses. A partner worth working with will ask for most of this anyway, as part of a proper discovery process. Having it ready means discovery confirms what you already know instead of uncovering surprises, and the project moves faster for it.

If you are preparing a vendor shortlist, use our free CMS RFP template. It turns the inventory, constraints and acceptance criteria into a buyer brief, with an editable vendor scorecard and three-year cost comparison.

If you would rather walk through your own situation with someone who has run this before, book a call. Our CMS replatforming service sets out how that discovery turns into a written scope and a fixed price.

FAQ

What should be on a CMS migration checklist? The client-side checklist runs in five stages. Write down the outcome the migration is meant to produce, and name the people who will use the system daily. Inventory the content you hold and decide what not to bring, and list every tool connected to the current CMS. Flag the URLs that carry bookmarks, inbound links, or search rankings, and note any deadline such as a vendor end-of-support date. Agree who signs off, how done is defined in writing, and what the scope, price, and date are. Then plan the landing: a verification step before cutover, a rollback answer, and a quiet window for the switch.

What do you need to prepare before a CMS migration starts? The things only your side holds. A written goal, a content inventory good enough to size the work honestly, a decision on what content to leave behind, a list of the systems wired into the CMS, and the URLs that matter. None of it requires understanding the code, and a partner worth working with will ask for most of it during discovery anyway. Having it ready shortens discovery and lets the sizing rest on verified facts.

What happens to your URLs during a CMS migration? Every address that people bookmark, that other sites link to, or that ranks in search is an asset, and when URLs change those addresses need redirecting. The work starts before anything moves. You do not have to build the redirect map yourself, but you should confirm your partner treats it as essential.

Is this checklist for enterprise CMS migrations too? The five stages hold at any size, and this version is written for the non-technical team on a mid-sized project. Enterprise scale adds work to each stage: content governance across several teams, a URL inventory large enough to need its own tooling, and sign-off paths that run through more than one department. Where the estate is that size, the CMS replatforming service sets out how the scope gets written and priced.

What does a CMS migration project plan look like? Six stages: discovery, content mapping, a trial migration, verification of a full migration rehearsal, cutover, and a settling-in period. Give each stage an owner, dependencies and evidence required to proceed. Your organisation approves content scope, publishing rights, mapping exceptions and the cutover decision. Set provisional dates after discovery, then confirm launch against verification evidence, the final content-sync plan and a rehearsed rollback procedure.

Who should sign off on a CMS migration? One person, or a clearly defined path, with the authority to approve scope and make decisions. Establishing who that is before the first sprint prevents the most common source of delay, which is a project waiting on a decision nobody has the authority to make. Alongside it, ask that acceptance criteria sit next to each piece of work, so whether something is finished has an answer both sides agreed in advance.