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.

Before you start, get clear on the why

• Write down what you are actually 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.
• 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 is empowered 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.

The point of doing this first

None of these 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.

For the flip side of this list, the things to insist your partner does, see the dos and don’ts of a CMS migration. And if you would rather walk through your own situation with someone who has run this before, book a call.