If your team has already picked a new platform and now has to move over, the hard part is rarely the import. The hard part is that writers, editors and approvers have a way of working that mostly functions, and a CMS migration content workflow plan has to carry that over without breaking it. This guide is for the marketing lead or content owner who has to run the move. By the end you will have a website content migration plan, a sequence you can follow that accounts for the people and the URLs both.
This guide covers the mechanics of the move itself. It does not help you choose a CMS, and it does not cover changing your content strategy. Those are separate jobs, and mixing them in is one of the easier ways to make a migration harder than it needs to be.
You will need a few things before you start. Someone has to be willing to own the project, you need access to your current CMS and your analytics, and you need a staging or test area in the new system where you can try things without publishing them.
Step 1: Give every part of the move an owner
Start with people before you touch any content. Name one migration lead, and then name an owner for each piece of the work. That usually means technical setup, the content inventory and the decisions that come out of it, content QA, redirects, contributor training and launch approval. One person can hold more than one of these on a small team, but each one needs a name next to it.
Bring editors and a few representative writers or freelancers into the planning, not only the person who administers the CMS. They are the ones who know where the real handoffs happen, and they will notice things an administrator won't. Keep a short decision log as you go, covering anything that changes how work is handed off, published or owned. It saves you from having the same argument again in week three.
You are done with this step when every workstream has one named owner, someone who can make the call when there is a disagreement, and a clear place to raise blockers. The editorial team should also know who to ask about workflow and access questions.
Common mistake: Treating the migration as an IT-only project. A technically clean import can still leave writers unable to submit work or editors unable to do their review and publishing, and you only find out on the first Monday.
Step 2: Inventory your content and decide what happens to each piece
Before you migrate content to new CMS fields and templates, build a content register. It is a plain spreadsheet that lists what you have. Count and identify your pages, posts, documents, images or image libraries, forms and anything else the team relies on. For each item, write down its current URL, content type, owner, editorial status and what you intend to do with it, which is keep, revise, merge or retire.
You can use your sitemap, analytics, server logs and Search Console data to find the pages that matter most and the ones that get visited a lot. Google's sitemap overview is a decent place to start if you aren't sure what yours contains. The exact method depends on how your current site is built, so use whatever gives you a complete list. If your site is already in DeepSmith's Content Map, it holds each page with a topic and a funnel stage, which can seed the register. It isn't a migration tool and it won't do the move for you, but it saves some typing.
A migration is a good chance to deal with material that is out of date, duplicated or superseded, so you don't need to reproduce all of it automatically. If you aren't sure how to decide, the guides on what a content audit adds beyond an inventory and on whether to refresh, rewrite, prune or redirect walk through that call page by page. Put your in-progress and scheduled drafts in the register too, so they don't get lost in the move. That last one is a check for your own team, not something every import requires.
You are done when every known item has a disposition and an owner, and you can say which things will be copied as they are and which need editing, merging or removing.
Common mistake: Assuming the visible navigation is the full inventory. Documents, forms, image libraries and less visible pages are often relied on by readers or staff, and they are the ones that get forgotten.
Step 3: Write down the workflow your team actually uses
This is the step that protects your editorial process, so give it some time. Pick a representative piece of work and follow it from assignment or creation through review to publication. Note each stage, who owns it, what has to be true before the work moves on, who can approve or publish, and what happens when someone asks for revisions. If there are special gates, like a legal review, capture them as well. If a blog post goes through a different route than a landing page, document each route separately.
A workflow is more than a list of status names. It is a set of stages, the moves that are allowed between them, and the permissions that decide who can make each move. A simple mapping table keeps that visible, and you can fill in the last column once you know what the new CMS can do.
| Current stage or handoff | Responsible role | Entry or exit condition | Next stage and decision-maker | New CMS equivalent |
|---|---|---|---|---|
| Drafting | Writer | Draft is ready for review | Editor reviews | To be mapped |
| Editorial review | Editor | Review complete or changes needed | Writer revises, or approver advances | To be mapped |
| Specialist review | Named approver | Required approval recorded | Publishing owner | To be mapped |
| Ready to publish | Publishing owner | Content approved and checked | Publish or schedule | To be mapped |
Those stage names are only examples for planning. Your own process is the source of truth, and some teams won't have a specialist review at all. If you do want to look at how teams build review gates for compliance and brand, this guide on editing workflows with compliance and brand gates shows one way to lay them out.
You are done when the team agrees on one workflow map that shows the real handoffs, the approval gates, who decides, and the exceptions. It should be clear enough that you can hold it up next to the new CMS configuration and compare them.
Common mistake: Rebuilding a generic "draft, review, published" flow without checking whether you really have separate editors and specialist approvers. The opposite mistake is just as common, which is carrying over every old status even when nobody uses it. A workflow that is too rigid frustrates people, so check how much your new CMS can actually be configured before you promise a one-to-one copy.
Step 4: Map your content structure, roles and permissions
Now compare the old system and the new one. Look at content types, fields and page structures, and note anything that needs to be transformed or handled by hand. Then go through your workflow map and assign each person or team to a role in the new CMS. For every role, check which actions it can take, such as creating, editing, submitting for review, approving, publishing or managing other users.
Your CMS migration content workflow only works if the roles behave the way you expect, so don't assume role names carry over. WordPress, for example, documents a set of predefined roles that includes Super Admin, Administrator, Editor, Author, Contributor and Subscriber, each with its own capabilities. Those names belong to WordPress. Another system might use different names, or the same name for something different, so look at what the target CMS really allows.
The most useful test is to create accounts with the roles contributors will actually receive and try the workflow with them. In some CMS training material, a "Submit" button in place of "Publish" is the signal that someone else has to approve the work. The labels and behavior differ by platform, so check yours rather than relying on what another system does.
You are done when the new content model has been checked against your inventory and every contributor or editorial function has the access it needs. Nobody should end up with publishing or admin powers that the old process never gave them.
Common mistake: Creating accounts and never checking what those accounts can do. You find out a writer can publish straight to the live site, or an editor can't approve, and by then it is a launch-week problem.
Step 5: Map old URLs to new destinations before launch
A URL map is a list of each important old URL and where it should go in the new site. Start with the pages that matter most, using your sitemap, server logs or analytics, and Search Console data to find them. For every URL whose page is moving, changing, merging or going away, decide what happens to it. Do this together with your content dispositions from Step 2, so the map reflects where things really end up and not an assumption that every page has a one-to-one copy.
For a permanent move, Google's guidance on site moves with URL changes recommends server-side permanent redirects where you can do them, such as HTTP 301 or 308, and says to avoid redirect chains. Client-side redirects are described as a last resort. For content you are not keeping or have merged elsewhere, make sure the old URL returns an appropriate 404 or 410 and doesn't send visitors to something unrelated. Google also suggests keeping redirects in place for as long as you can, generally at least a year, and you may want to keep them indefinitely for users.
If you are weighing which pages to merge or drop as part of this, this piece on consolidating, redirecting or deleting low-value pages is a good companion. And if your migration is part of a bigger site change, the site redesign migration playbook covers how to keep AI visibility intact while URLs shift.
You are done when the old-to-new mapping has been checked, someone owns putting the redirects in place, deleted and merged content has a stated outcome, and you have a way to test the rules.
Common mistake: Sending a lot of unrelated old URLs to the new home page, or leaving redirect decisions until after launch. A redirect should land on something relevant, and a missing or poor map breaks both reader journeys and search.
Step 6: Run a test migration in a non-live environment
Don't start on the live site. Use staging or another non-production environment and migrate a sample that includes the content types and workflow cases your team really uses. Then check what came across. Look at formatting, internal links, images and embedded media, forms, navigation and how pages look on a phone, and try the editorial actions too.
Ask contributors and editors to do realistic tasks in the test environment and not just look at it from an administrator's view. A sample will show you formatting problems, broken links and confusing steps early, while they are cheap to fix. Your internal links deserve a specific look, and a process like the one in this internal link audit guide helps you find gaps and orphans before your readers do.
For a large site where it is technically possible, Google also recommends moving an initial section first so you can see the effect on traffic and indexing before you move the rest. If you do this, pick a section that changes less often and isn't exposed to unpredictable events. Whether a partial launch is right for you depends on your own risk and how your site is built, so treat it as an option and not a requirement.
You are done when the problems you found in the sample are recorded and resolved, and contributors can complete representative work using the roles and workflow you set up.
Common mistake: Treating a successful data import as a successful migration. The import finishing only tells you the data moved. It doesn't tell you whether people can work.
Step 7: Re-onboard contributors and test the handoffs
Give writers, editors, approvers and publishers the access and information that fits their role. Show them where they start work, how they submit it, where review feedback shows up, how to make revisions and how work gets approved or scheduled. Short walkthroughs for each role, followed by a practice task they do themselves while someone is around to answer questions, tend to work better than a long all-hands session. Give people a clear contact or a place to escalate.
Then test the handoffs with the actual people, before launch. Have a writer find a migrated piece, edit it or submit it as their role allows, respond to a review comment and confirm who gets it next. Ask editors to compare migrated pages against the current ones, including recent changes, how they display on a phone, menus, links and breadcrumbs where they apply. Keep the instructions specific to your CMS. Product training materials often separate submitting content from publishing it, and some suggest an orientation for new editors with extra help for experienced ones.
If you are already thinking about how review and approval will run over the long term, this guide on content governance is a useful read for after the move.
You are done when representative contributors can do their normal tasks, editors can carry out the review and approval steps they own, and any access or instruction gaps have an owner and a fix.
Common mistake: Training only the administrators, or treating an account invitation as onboarding. The best acceptance test is whether the people who do the work can do it, with the right permissions, in the new environment.
Step 8: Set a freeze or final sync plan, then cut over
Decide on a cutoff after which the old CMS will stop receiving new content. If a full freeze isn't practical for your team, define how late changes will be captured and reconciled instead. Tell writers, editors and publishers what the cutoff is and how to handle urgent changes. Before the final move, reconcile everything that changed since your test or first import, especially in-progress and scheduled work.
At cutover, switch on the redirects you planned and check that any development-only crawling blocks or noindex rules are removed the way you intended. It's easy to leave a staging block in place and wonder weeks later why nothing is being found.
Where you can, avoid bundling unrelated site changes into the same launch. Google advises changing one thing at a time, and keeping the CMS move apart from other major changes makes it much easier to work out what caused a problem if something goes wrong. Teams doing a bigger move, such as a full platform change for a large site, may find this enterprise migration guide useful for how to phase it.
You are done when the team knows which system is the authoritative one, outstanding work has been reconciled, the new site is ready for visitors and search crawlers as intended, and the redirect plan is live.
Common mistake: Migrating a moving target without agreeing how new or revised material gets across. The freeze is a coordination control and not a set number of days. Choose its timing from your migration plan and editorial calendar, and don't borrow someone else's duration.
Step 9: Check the live site and review how the team is doing
After launch, check your redirects and URLs, look for unexpected HTTP errors, watch crawl activity and keep an eye on normal user traffic. Compare analytics against a sensible baseline from before the move. Test your forms and where their submissions go, make sure images and embedded media load, look through internal links and navigation, and confirm the new CMS still supports the handoffs and permissions you agreed on.
Just as important, ask contributors where they are getting stuck, and look at whether real content work is moving through the new process. If traffic does drop, this walkthrough on recovering organic traffic after a site migration gives you a place to start diagnosing it.
Put follow-up reviews on the calendar. One practitioner guide suggests checking in at 30 and 90 days, which is a practical set of checkpoints and not an industry standard. Keep watching your redirects, and keep them in place for the period Google recommends where you can.
You are done when the owner has a record of the checks, unresolved issues each have an owner and a fix, the editorial team is back to its normal work, and the follow-up reviews are scheduled.
Common mistake: Calling it a success at go-live. The new site loading doesn't mean the migration is finished. Content, URLs, forms, traffic and the contributor experience all need to be checked once real use starts.
Keep one working record through the whole move
A website content migration plan stays easier to follow when it lives in one place. The easiest way to keep these steps connected is a single working document. It doesn't need to be fancy, and it isn't a vendor template, just a practical way to coordinate. It holds seven things.
- Your content inventory and disposition: keep, revise, merge or retire, plus the owner, current URL and the destination or removal outcome.
- Your workflow map: content type, current stage, role responsible, approval condition, allowed next step and the new CMS equivalent.
- Your role map: people or teams, target role, the capabilities they need and the result of testing them.
- Your URL map: old URL, destination or removal outcome, redirect rule and test result.
- Your migration test log: sample content, issues found, owner, fix and retest status.
- Your contributor acceptance record: the task, the role, the outcome, any confusion or access problem and who follows up.
- Your launch and follow-up checks: content and links, forms, media, redirects, errors, crawling, traffic, workflow use and review dates.
A few things are worth keeping in mind as you work through it. What has to survive is the function, the handoff and review gate and who has decision authority, and not necessarily the label on each status. Workflow features vary by CMS and sometimes by content type, so verify the target system and don't assume a feature exists. Keep separate editorial routes where the work needs them, such as a legal review, and don't add approval steps just because the CMS offers them. There is also no reliable universal figure for how long a migration takes, how long a freeze should be, how big a test sample needs to be or what traffic you will keep, so plan from your own site and be wary of anyone who quotes one.
What to do next
If you only need to move blog to new CMS and nothing else, the same nine steps still apply, just with a smaller register. Start with Step 1 this week and get the owners named, because every other step depends on them. Then build the content register, since it feeds your URL map and your test sample. Once the new site is live and your team has settled in, you will probably want to get back to publishing regularly. If that is where your attention goes next, try DeepSmith free to produce your new articles and publish them straight to WordPress, Webflow, Strapi, Sanity or Contentful from Produced Content. It doesn't move your legacy content or recreate your editorial workflow, but it takes care of the writing and publishing side once the move is done.
