Moving from shared hosting to a modern platform: the migration plan
How to move a website off a traditional shared hosting account onto a modern platform without losing email, rankings or a weekend, in seven steps.
The short answer
A traditional shared hosting account usually holds more than the website: the mailboxes, the DNS, a database, scheduled jobs, old redirects, forgotten subdomains and years of files. Moving to a modern platform therefore starts with an inventory, not with the site. Email is separated first and moved to a dedicated provider, because it is the most common casualty of website migrations. The site is then rebuilt or moved into version control on the new platform with a pipeline and previews, redirects are prepared for every old address, and DNS is switched in a quiet window with a low time-to-live. The old account stays readable for a period while everything is verified, and it is cancelled with a checklist. Done in that order, the site is never down and nothing is lost; done by pointing DNS at the new host and hoping, something always is.
The seven steps
| Step | What | Why |
|---|---|---|
| 1. Inventory | Everything on the account: site files, database, mailboxes, DNS records, subdomains, cron jobs, redirects, certificates, third-party connections | You cannot move what you do not know is there |
| 2. Separate email | Move mailboxes to a dedicated provider; update mail records; verify sending and receiving | Email must never depend on web hosting |
| 3. Prepare the new site | Rebuild or migrate into a repository; set up the platform, pipeline and previews; recreate forms and integrations; test on the preview address | The new site is complete and tested before anyone points at it |
| 4. Redirect map | Crawl the old site; list traffic-bearing addresses; map each to its new address; configure on the platform | Rankings travel through redirects |
| 5. DNS switch | Lower time-to-live a day before; switch the web records in a quiet window; keep mail records untouched | Fast, reversible propagation |
| 6. Verify | Site, forms, redirects, certificates, subdomains, integrations, analytics, search console | Nothing assumed |
| 7. Cancel | After a period, with the checklist: data exported, nothing still pointing at the old account | No surprises after cancellation |
The details that catch people
- Mail records changed by accident when the web records are updated. Write down every record first; change only the web ones.
- Subdomains nobody remembered, pointing at the old account: a staging copy, a tool, a campaign page. The inventory finds them; each is moved, redirected or removed.
- Scheduled jobs on the old server doing something the business relies on: a report, a sync, a backup. They must be recreated or replaced.
- The database, if the old site had one: exported, imported or replaced by the new content model, with counts reconciled.
- Forms whose submissions went through the old server’s mail function: rebuilt on a function with a sending service.
- Certificates and HTTPS: issued automatically on the platform; verified for every subdomain.
- Analytics and search console: verified on the new setup; sitemap submitted; indexing watched.
What the business notices
Nothing during the move, if it is done right: the site keeps working, email keeps flowing, and one morning the site is faster and the pipeline exists. Afterwards, hosting is in the business’s own account at the provider’s price, changes go through previews, the old shared account is gone, and the monthly maintenance is lighter because there is less to maintain.
What this means for you
Move off shared hosting in order: inventory, separate email, prepare the new site with previews, build the redirect map, switch DNS in a quiet window with a low time-to-live, verify everything, then cancel with a checklist. The move is uneventful when planned this way, and the result is a faster site in your own account with a pipeline instead of a control panel.
Frequently asked questions
Will our email break when we move the website?
Only if the mail records are changed by mistake or the mailboxes lived on the hosting account and were not moved first. Move email to a dedicated provider before touching the website, write down the current DNS records, and change only the web records when the site moves. Email is the most common casualty of website migrations and the most avoidable.
Can we keep the old address structure?
Mostly, and where the new site changes it, redirects map every old address to its new one. A crawl of the old site plus the list of addresses that receive traffic produces the redirect map; the platform serves the redirects. Rankings survive complete redirects; they do not survive pages left to 404.
How long does the move take?
For a typical business site: a week or two to inventory, separate email and prepare the site on the new platform with previews; a quiet window of an hour for the DNS switch; a period of verification afterwards; then cancellation. The site is never down if the switch is planned, because the new platform is serving before DNS changes and the old account keeps serving until it propagates.