The buying testA safe CMS migration is not a successful import. It is a controlled change that preserves meaning, routes, editor work and the option to stop.
A CMS migration agency should audit before it estimates
The first deliverable should be an inventory, not a platform recommendation. The agency needs to count content types, entries, locales, assets, references, URLs, forms, search indexes, integrations and editorial roles. It should also identify content that is duplicated, obsolete, private or impossible to export cleanly.
Imagine a university site with 4,000 pages, 60 course records and a separate events database. A page count misses the structured records, expired events and links between courses, departments and staff. Estimating from the visible navigation would turn discovery gaps into change requests later.
Start with a website content audit, but add technical fields that editorial reviews often omit: stable identifiers, reference direction, asset ownership, publication state and export access. The estimate should state which unknowns remain and how they will be resolved.
Model meaning before moving content
A migration should map meaning, not copy fields by name. The target model must show which objects are reusable, which values are required, how references work and what editors may change without breaking a page. This is where a new CMS either improves operations or preserves old confusion in fresher software.
Suppose the old CMS stores an author as plain text on every article. The new model may use one author record referenced by many articles. The migration needs a rule for duplicates, missing biographies and authors with the same name. A script that simply copies the old string cannot make those decisions.
Sanity's current schema and content migration guidance uses code-based migrations, dry runs and dataset backups. The specific tool will vary, but the buying principle holds: transformations should be versioned, inspectable and repeatable before they touch production data.
Preserve URLs unless change earns its risk
A CMS change does not require a URL change. Keep stable routes when they still describe the content and support the product. When a route must move, require a one-to-one mapping, server-side redirect, updated internal links, correct canonical URL and a clear response for content that is intentionally removed.
For example, merging `/services/advice` and `/consulting/advisory` into one stronger page is a content decision. Redirecting every retired service to the homepage is not. It hides gaps from the migration report while sending users and search engines somewhere irrelevant.
Google's site move guidance recommends preparing an old-to-new URL map, testing redirects and submitting the new sitemap. It also recommends keeping redirects for at least one year. A technical SEO audit can establish the current crawl and index baseline before launch.
Test the editor workflow, not only the website
Editors are users of the product. The acceptance plan should cover creating, reviewing, previewing, scheduling, localizing, publishing, correcting and unpublishing real content. It should include permissions and the awkward states that demos skip, such as a missing image, expired campaign or translation waiting for approval.
Picture a marketing manager preparing a launch in three languages. The new frontend may look perfect while preview shows the wrong locale and scheduled publication ignores the legal approval state. Those are migration failures even if every imported entry exists in the database.
Contentful's import and export documentation notes that releases, tasks, workflows, memberships and some extension setup do not move with a basic export. The agency should list similar platform limits and name the manual or scripted work required around them.
Rehearse the migration with a measurable reconciliation report
Run the migration more than once in a production-like environment. The first rehearsal exposes mapping and data problems. Later runs prove that the process is repeatable and that content changed since the first export can be moved through a controlled delta rather than a long publishing freeze.
A useful reconciliation report compares source and target totals by type, then lists skipped records, transformed fields, broken references, missing assets and validation failures. For a catalogue with 800 products, a target count of 800 is only the first line. The team still needs to know whether each product kept its variants, documents and canonical route.
The final rehearsal should use the same scripts, order and permissions planned for launch. A hand-edited staging database can make the demo green while leaving the real run untested. Ask who signs the reconciliation report and which differences block release.
Compare CMS migration proposals through evidence
Strong proposals connect each risk to an artefact you can inspect. They do not hide the difficult work inside a line called implementation. The table below turns common promises into reviewable evidence.
For example, "zero SEO impact" is not a responsible promise because search systems and external links sit outside the agency's control. A tested route map, crawl comparison and monitoring plan are credible evidence. The proposal should make the same shift from promise to proof for content and editorial work.
| Proposal area | Evidence before launch | Evidence after launch |
|---|---|---|
| Content | Inventory, field map, validation rules and rehearsal report | Source-to-target reconciliation and sampled records |
| URLs | Route map, redirect tests, canonical rules and crawl baseline | Status, canonical, sitemap and index monitoring |
| Editors | Role matrix and task-based acceptance sessions | Publishing support, issue ownership and training gaps |
| Operations | Cutover runbook, stop conditions and rollback rehearsal | Monitoring, incident path and dependency ownership |
Make launch reversible before the clock starts
The cutover plan should name the content freeze or delta window, migration order, DNS or routing change, cache behavior, smoke tests, decision makers and maximum time allowed for recovery. It should also define the point after which rollback becomes unsafe because editors have started changing data in the new system.
Consider a publisher launching at 06:00. If article publishing fails at 06:20, the team needs to know whether to switch traffic back, keep the new frontend while restoring the old editor, or fix forward. "The developers will be online" is staffing, not a rollback plan.
Accessibility belongs in these release checks. W3C guidance on planning and managing accessibility places evaluation and responsibility throughout delivery, not at the end. Test representative publishing and user journeys before and after cutover, including keyboard use, errors and content added through the new model.
A new CMS is not always the right answer
The serious objection is cost and disruption. A migration may be a poor investment if the real problem is governance, neglected templates or an editor process nobody owns. Changing platforms does not decide who approves a claim, retires an old page or maintains a taxonomy.
A small team frustrated by slow campaign publishing may need two repaired templates and clearer permissions, not a new content platform. A responsible agency should compare repair, partial migration and full replatforming against the same outcomes.
Use the website redesign strategy when the project also changes journeys and conversion paths. Bring the constraints from the website design brief so the CMS decision follows the work people need to do.
CMS migration agency checklist
If you can share the current CMS, approximate content inventory and three critical editorial workflows, Seuil can test the migration shape before a large build estimate appears. Send those inputs to bonjour@seuil.digital and ask for the smallest scope that proves the content model and cutover plan.
- The proposal starts from a signed content, URL, integration and role inventory.
- The target model includes field rules, references, locales and publication states.
- Transformation scripts are versioned, repeatable and safe to dry-run.
- Editors test real preview, approval, scheduling and correction tasks.
- Every changed URL has an explicit destination or removal decision.
- Rehearsals produce reconciliation reports with blocking thresholds.
- Cutover has named stop conditions, rollback ownership and post-launch monitoring.
- Handover includes scripts, models, route maps, runbooks and known limits.