Website rebuilds often begin with “The old CMS is difficult to use,” then migrate only body copy and images. Categories, authors, downloads, forms, SEO titles, and redirect rules were never documented, so the team must reconstruct them after launch.
A technology migration needs an inventory of assets and behavior that maps the old system’s content, functionality, and search signals to the new one.
01 Crawl and Export the Complete Current State
Collect every URL, status code, title, description, canonical, page type, traffic level, backlink, media asset, and internal link.
Also record admin roles, publishing workflows, form destinations, search, downloads, third-party scripts, and scheduled jobs.

02 Create a Content-Model Mapping
Define how articles, case studies, products, categories, tags, and custom fields in the old CMS correspond to the new system.
Do not combine structured fields into one rich-text block; doing so removes filtering, templating, and multilingual capability.
Technology Migration Checklist
| Category | What to Migrate | Acceptance Method |
|---|---|---|
| URLs and SEO | Paths, redirects, metadata, canonicals | Crawl and compare old and new |
| Content | Body, fields, categories, authors, dates | Reconcile counts and sample records |
| Media | Images, PDFs, alt text, links | Files are accessible and referenced correctly |
| Functions | Forms, search, filters, downloads, login | End-to-end task tests |
| Integrations | CRM, email, analytics, payments, maps | Validate in the real environment |
| Permissions and workflow | Roles, review, preview, publishing | Test with different accounts |
| Operations | Backups, monitoring, logs, deployment | Restoration and alert drills |

03 Preserve URLs and Map Necessary Changes One to One
Keep paths for high-value pages whenever possible. When a path changes, map old to new instead of redirecting everything to the home page.
Attachments and image URLs may have backlinks too, so include them in the migration.
04 Migrate in Batches and Validate Automatically
Migrate a small set of different templates first, verify fields, encoding, images, and links, then execute the full batch.
Use scripts to compare counts, missing fields, status codes, and content hashes, and manually sample high-value pages.

05 Redesign the Workflow for Editors
The new CMS should not simply copy the old admin. Define how editing, approval, preview, scheduling, rollback, and multilingual work will operate.
Train editors before launch and retain read-only access to the old system for a period of verification.
06 Prepare Rollback and Post-Launch Monitoring
Retain complete backups, switch procedures, owners, and rollback conditions. After launch, monitor 404s, forms, search, indexing, performance, and content errors.
Do not close the old system and domain immediately. Retire them according to plan after data and operations are stable.
Frequently Asked Questions
Can we redesign during the migration?
Yes, but combined changes increase risk. Maintain clear mappings and validate in stages.
Must every old page be migrated?
No. A page can be retained, merged, rewritten, or removed, but every URL needs an explicit decision.
Can the old CMS database be imported directly?
It usually needs field transformation, cleaning, and validation. Do not assume compatible structures.
Is a traffic decline normal after migration?
Short-term fluctuation can occur, but investigate 404s, redirects, and indexing problems promptly.
When can the old system be closed?
Close it according to plan after content, functions, search, and backups are stable. Retain important evidence and a read-only backup.
| Service | View |
|---|---|
| Related service | View service details |
| Project inquiry | Contact JVDS |
| Design and website articles | View all articles |