Separate content migration from redesign
Moving to a new CMS changes how information is stored and edited. A visual redesign changes how it is presented. Doing both in one project is possible, but the risk of losing useful pages, metadata or internal links becomes much greater. Agree on which existing content should be retained, revised, consolidated or retired before the team starts moving templates.
Create a shared inventory of URLs, page titles, headings, featured images, downloads, canonical targets and structured data. Record who owns each decision and which pages drive valuable enquiries.
Design the content model first
Look for repeated content structures: services, articles, projects, team members, FAQs and multilingual variants. Define fields and relations rather than putting all data into one unstructured editor. A project may contain industry, scope, gallery, technology stack and testimonial links. An article needs a publication workflow and a real author or editorial team.
Build a small representative batch of content first. Check whether editors can create, preview and publish it without touching the codebase.
Map every important URL
Preserve existing URLs when practical. For changed URLs, document a direct permanent redirect from the old address to the best matching new page. Do not redirect every removed page to the homepage; users who searched for a specific topic need an appropriate destination.
Verify canonical tags, internal links, XML sitemaps, hreflang where appropriate, and whether draft/private pages are excluded. A migration should not launch until the team can compare the old URL inventory against the destination set.
Test more than visible content
CMS migrations often break less visible features: forms, newsletter opt-in links, embedded media, downloads, image alt text, author pages, dates, structured data, analytics events and search. Test editor permissions and backups; verify that restored data can reproduce a usable site, not only that a backup file exists.
For international sites, check translated page relationships and whether fallback content is clearly marked instead of indexed as if fully localized.
Plan an accountable launch
Prepare a pre-launch crawl, record key current URLs and export the database. During launch, deploy redirects, verify indexing directives and submit the correct sitemap. After launch, monitor crawl issues and enquiry submissions; address unexpected 404s and incorrect canonical tags promptly.
Keep the old content and hosting backup until the replacement has passed agreed acceptance tests. Avoid changing URLs again immediately unless a verified issue requires it.
An example redirect decision
Imagine an existing article about maintaining a small-business website at /blog/site-maintenance-guide. The new CMS introduces /insights/website-maintenance. If the topic and content remain substantially equivalent, a direct permanent redirect may be appropriate. If the old article had distinct information that the new page does not cover, preserve the useful material or choose a closer target.
Keep redirect decisions in a shared map with old URL, new URL, status, page owner and test result. This small operational step prevents an expensive round of reactive fixes after launch.
Editorial training is part of a successful migration
Before signing off, ask one real content editor to publish a draft article in staging, add a featured image with alt text, adjust metadata, preview the result and unpublish it. Do the same with a portfolio gallery if case studies are important to sales.
Provide a short written guide for recurring tasks and an escalation contact for unusual errors. If every routine change still requires a developer, the CMS migration has not delivered its central operational benefit.
CMS migration questions worth asking
- Which content fields and relationships are being migrated?
- Which pages keep their current URLs?
- Who writes and validates the redirect map?
- How are media, articles and images associated correctly?
- Can editors preview drafts and roll back an update?
- How are staging content and search indexing separated?
AppsBrain supports CMS architecture, content-model design and business-site migrations. Start with CMS development or contact AppsBrain and share your current site map and editorial requirements.
Try a focused pilot before the main commitment
Select ten representative URLs: a service page, an article, a portfolio entry, a redirected legacy URL, an image, a PDF and an archive. Compare the old and new title, content intent, canonical, HTTP response and internal links before moving the whole site.
Information to include in the handover
Create an asset manifest, old-to-new URL map, metadata export, image-alt inventory, author/date plan, structured-content mapping and rollback procedure. Do not assume that a CMS exporter preserves every custom field, embedded image or access permission.
How to review the result
After launch, sample live URLs rather than only checking the homepage. Review search crawls for soft 404s, loops, omitted pages and unintended canonical targets. Protect the ability to restore the previous state if a critical content relationship is lost.
A useful acceptance meeting should include the future content or operations owner, not only the person who commissioned the design. Ask participants to demonstrate the normal task and an awkward edge case, then record fixes, responsible owners and unresolved risks. Store those decisions somewhere the next developer or editor can actually find them.
Before publishing, confirm current technology versions and any local regulatory assumptions with authoritative sources. These planning exercises are suggestions, not evidence of a completed AppsBrain client project.
A practical release sign-off
Before anyone calls the change complete, record the current state and choose at least three real tasks that matter to customers or editors. Assign an owner for reviewing each task and keep private data out of screenshots shared for review. Test the expected successful path, an incorrect or missing-input path, and the behavior when a dependency such as email or a third-party provider fails. Retain the earlier working version until the new one is accepted, with a documented procedure for reversing the release. After launch, schedule a short review of feedback and support questions; unexpected operational friction is often visible there before it appears in an analytics dashboard.