Editorial illustration; it does not show a real migration or website.
Moving a website sounds like a design project. The new pages look better, the content is tidier and the hosting bill may be lower. Then the new site goes live and visitors discover that old links return 404 errors, search results point to the wrong pages, forms stop working or the domain still reaches the old server.
The difficult part of a migration is not copying files. It is preserving the promises the old website made: the same useful addresses, the same important content, the same customer journeys and a clear way back when something goes wrong.
Quick Answer
A safe website migration has five phases: inventory the current site, design the new URL and content structure, prepare redirects and technical settings, test the new site privately, and switch traffic with a rollback plan. Do not start by deleting old pages. Start by recording what already works and which URLs people actually use.
1. Define what is changing
“Migration” can mean several different things. You might be changing the domain, moving to a new host, replacing a CMS, redesigning the frontend, changing URL paths, or doing all of them at once. Each extra change creates another place for a failure to hide.
Write down the scope before anyone edits the production site. For example:
example.comwill remain the domain.- The CMS will change, but the main page addresses will stay the same.
- The old
/services/pages will move to/solutions/. - The database and uploaded media will be copied to the new host.
- Email, payment, analytics and contact forms must continue working.
This list gives the team something more useful than “make the new site live”. It also exposes risky changes early. If the domain, platform and URL structure are all changing, you need extra time for testing and DNS planning.
2. Build an inventory of the old site
Create a list of existing URLs before you rebuild anything. Include pages, posts, images that receive traffic, downloadable files, feeds, XML sitemaps and important API endpoints. A crawler can help, but do not rely on a crawler alone: it may miss orphan pages, old campaign links and URLs that visitors reach from external sites.
Compare at least three sources:
- The current sitemap and server or application logs.
- Search performance data showing pages that receive impressions or clicks.
- Analytics, campaign links, support messages and bookmarks that reveal real user journeys.
Mark each URL as keep, merge, redirect, replace or retire. Preserve pages that still answer a useful question even if they are not fashionable. A low-traffic page may still be the page a customer uses when a product fails or an employee needs an old instruction.
3. Design the new structure before writing redirects
Draw the new sitemap and map every important old URL to a destination. A redirect table is more dependable than a collection of rules written from memory.
| Old URL | New URL | Decision |
|---|---|---|
/about-us/ |
/about/ |
Permanent redirect |
/services/old-package/ |
/services/ |
Merge and redirect |
/download/guide.pdf |
/resources/guide.pdf |
Move file and redirect |
/temporary-test-page/ |
— | Return a deliberate 404 or 410 |
Use a one-to-one destination whenever possible. Sending every old URL to the homepage may technically remove a 404, but it does not help a visitor who expected a specific guide or product. It also makes it harder to understand whether the migration worked.
Keep the new structure understandable to people. Short, stable paths are easier to share and maintain. Do not change a URL simply because a new CMS makes it possible. Every unnecessary change creates another redirect to test.
4. Prepare redirects and canonical URLs
When a page has moved permanently, configure a server-side permanent redirect from the old address to the closest relevant new address. The exact configuration depends on the web server, host or framework, so test it in a staging environment rather than pasting a rule into production and hoping.
Check both the status code and the destination. A correct redirect should not loop, point to another redirect unnecessarily, or send users from HTTPS back to HTTP. Watch for differences in trailing slashes, uppercase letters, query strings and language prefixes.
Review canonical links on the new pages too. Each important page should identify the URL that represents its preferred version. Update internal links so the new site points directly to the new URLs instead of forcing visitors through old redirects.
Google’s Search Central documentation recommends mapping old URLs to new URLs and monitoring the move. That advice applies beyond search engines: direct links in email, social posts and other websites also depend on the mapping being accurate.
5. Copy content, media and data carefully
Make a complete backup before the final copy. Export the database, uploaded files, configuration and any data that is not stored in the main CMS. Confirm that the backup can actually be opened or restored; a file that exists is not automatically a usable backup.
Then compare the old and new versions. Check titles, headings, images, captions, downloads, structured data, forms and access rules. A migration often “works” while quietly losing the small details that users notice: a missing PDF, a broken image variant, a form notification sent to the wrong mailbox or an account that can no longer log in.
Do not copy secrets into a public repository or a client-side configuration file while moving systems. Treat database exports, API keys and private uploads as sensitive material throughout the project.
6. Test the new site before changing DNS
Give the new site a private test address or restrict it behind authentication. Test representative paths on a phone and desktop, while logged in and logged out. The goal is not only to click the navigation. Test the journeys that matter to the business:
- A visitor arrives at an old bookmarked article.
- A customer submits a contact or order form.
- An editor publishes or updates content.
- A user downloads a file.
- A search engine crawler reaches the sitemap and robots file.
- An administrator restores a backup or disables the new deployment.
Use automated link checks where possible, then perform a human review of the most valuable pages. Automated tests can find a missing status code; they cannot tell you that a pricing explanation is now confusing or that the Malay translation disappeared.
7. Plan the cutover and rollback
Choose a quiet period and write the cutover sequence as a checklist. Freeze content briefly if the old and new systems could otherwise receive different edits. Record the final database export, deploy the tested version, verify the domain configuration, and only then direct traffic to the new environment.
Lowering DNS time-to-live shortly before a migration may help some resolvers refresh sooner, but it is not a guarantee that every visitor changes at the same moment. Keep the old environment available for a defined period and decide what happens to new form submissions or orders during the transition.
Rollback should be a real procedure, not the sentence “we can switch back”. Write down which DNS record, load balancer setting or deployment version must change, who can make that change and how new data will be reconciled.
8. Monitor the first days
After launch, monitor redirect errors, 404 responses, server errors, page speed, form submissions, search indexing and the most important conversion paths. Compare the new numbers with a normal period before the migration, but do not panic over one unusual hour.
Search engines may need time to recrawl and process redirects. That does not excuse a sharp increase in errors. Look for patterns: one directory returning 404s, one language version missing, or all query-string URLs being sent to the homepage.
Ask support and sales teams what they are hearing. A customer reporting that “the old invoice link no longer works” may reveal a problem that a homepage dashboard will never show.
Common mistakes to avoid
The most expensive mistakes are often simple:
- Launching before the redirect table is complete.
- Treating a redesign as permission to delete useful content.
- Testing only the homepage.
- Relying on DNS propagation as a rollback plan.
- Blocking the staging site from crawlers, then accidentally carrying the block into production.
- Leaving old admin accounts, test files or copied secrets on the new server.
- Assuming a green deployment means forms, email and payments are working.
My Take
The safest migration is usually the least dramatic one. Keep the domain and important URLs stable when there is no strong reason to change them. Separate structural improvements from visual experiments, and make each change observable. A new homepage is exciting; a reliable redirect table and a tested restore path are what protect the people who already depend on the site.
Bottom Line
Treat a website migration as a continuity project, not a file-copying exercise. Inventory the old site, map valuable URLs, prepare tested redirects, verify content and data, rehearse the cutover, and monitor the real user journeys after launch. If you can explain how to detect failure and how to return safely, the migration is ready for production.