Website migration without downtime, broken links or lost traffic
A migration is a logistics exercise wearing a technical costume. The code is rarely the hard part. Knowing exactly what exists today, and proving it still exists tomorrow, is.
What is website migration?
Website Migration is moving a site to a new platform, host or domain while preserving its content, URLs, search visibility and integrations. It suits Australian organisations replatforming, consolidating multiple sites, changing hosting providers or rebranding to a new domain, where the site must keep working for customers throughout the change.
Get a fixed written quote- Typical timeline
- 2 to 5 weeks
- What drives cost
- Scales with the number of URLs, the amount of non page data such as customers and orders, how many integrations must be reconnected.
- Best for
- Replatforming, host changes, domain changes and site consolidation
- You own
- Every account, credential and DNS record from the first day
- Built with
- Full crawl inventory, redirect mapping, staged cutover, rollback plan
Your handover
The four migrations people mean by that word
Clients say website migration to describe quite different projects, and the risk profile of each is not the same. A hosting move keeps the platform, the URLs and the content identical and only changes where the site runs, which is the lowest risk of the four when DNS is handled carefully. A platform migration rebuilds the site on new software and usually changes URL patterns, which is where search visibility is most exposed.
- 01Complete URL inventory with traffic and link data
- 02Migrate, redirect or retire decision for every URL
- 03Tested one to one redirect map
- 04Content and data migration with reconciliation report
- 05Integration and payment testing in the new environment
- 06DNS, certificate and email routing plan
- Written cutover runbook with rollback thresholds
- Pre cutover backup with a verified restore
- Two weeks of post migration monitoring and a closing report
More on the four migrations people mean by that word
A domain migration changes the address entirely, common after a rebrand or an acquisition, and requires every external link to be redirected while search engines relearn the new identity. A consolidation merges several sites into one, typically after a merger or when a group tidies up its brand portfolio, and brings the hardest content decisions because two pages often compete for the same subject. We establish which of these you are actually doing in the first conversation, since it determines the entire plan.
Backups are taken immediately before cutover and test restored beforehand, since an untested backup is a hope rather than a plan.
Inventory everything before you move anything
The single most common cause of a bad website migration is an incomplete picture of what exists. Sites accumulate things nobody remembers: a PDF price list linked from an email campaign that still runs, a landing page built for a trade show two years ago that a partner site links to, a subdomain running a form that finance depends on each month.
Nothing disappears by accident
We crawl the entire site, cross reference against server logs, analytics and Search Console so we also catch pages the crawler cannot reach, and pull the backlink profile to find external links pointing at URLs nobody internally is aware of. The output is a spreadsheet of every URL with its traffic, its inbound links and a decision: migrate, redirect, or retire deliberately. Nothing disappears by accident. That inventory becomes the checklist used to verify the migration afterwards, which is what turns it worked into it is verified.
- Full crawl plus log file and analytics cross reference
- Documents, images and downloadable assets included, not just pages
- Backlink profile checked for externally linked URLs
- Forms, integrations and scheduled jobs catalogued
- DNS records, email routing and certificates recorded
- Third party scripts inventoried with an owner named for each
How the engagement runs
How the cutover is actually executed
Downtime almost always comes from DNS being handled casually or from a step nobody rehearsed. We rehearse the whole sequence, on a schedule agreed with you, at the quietest hour for your audience rather than whatever suits us.
- 01Stage 1Build and populate the destination environment, kept private and blocked from indexing
- 02Stage 2Run the content and data migration repeatedly until the reconciliation report is clean
- 03Stage 3Load the redirect map and test every rule automatically, including query strings and trailing slash variants
- 04Stage 4Verify forms, payments, integrations and scheduled tasks against the new environment
- 05Stage 5Reduce DNS TTL 48 hours ahead so propagation is measured in minutes rather than days
- 06Stage 6Freeze content changes on the old site, take a final data sync and a full backup
- 07Stage 7Switch DNS, verify certificates, then walk the top pages and every conversion path manually
- 08Stage 8Monitor errors, redirect hits and enquiry volume for two weeks with the rollback path still available
Two decisions on your side that keep the project moving
Before cutover night we agree who is available, what each person is responsible for and how we will confirm success. That sounds like process for its own sake until the one occasion something behaves unexpectedly and nobody can reach the person who holds the domain registrar login. For groups consolidating several sites at once, such as a franchise network merging location sites into one, we stage the moves rather than switching everything on a single evening.
Redirects done properly, and what improper looks like
A redirect map is the contract between your old site and your new one. Improper looks like this: a rule that points every old URL to the home page, which tells search engines those pages are gone and irritates anyone following a link from an email. Or redirect chains three hops long because nobody consolidated the rules from the last two migrations. Or rules that handle the tidy examples and miss the versions with tracking parameters, uppercase characters or missing trailing slashes.
Old redirects from previous migrations are folded in so nothing accumulates
Proper means one to one wherever an equivalent page exists, permanent 301 responses rather than temporary ones, no chains, and a rule set tested programmatically against the full URL inventory before launch rather than spot checked by hand. Old redirects from previous migrations are folded in so nothing accumulates. We keep the map as a documented artefact you own, because in three years somebody will need to know why a rule exists. This work sits alongside broader technical SEO when the site has deeper crawl issues worth fixing while everything is already open.
Data, integrations and the parts that are not pages
For anything beyond a brochure site, the content is the easy half. Customer accounts, order history, subscription states, saved carts, member logins and uploaded documents all need to arrive intact and reconciled against the source, not merely copied and hoped for. Passwords cannot usually be migrated between systems in readable form, so a reset flow has to be planned and communicated before customers discover it at an inconvenient moment.
Integrations need equal attention
Integrations need equal attention. Payment gateways have separate production credentials, webhooks point at old endpoints, accounting connectors need reauthorising and API keys registered to a departed employee will be discovered at the worst time. We test each integration end-to-end in the new environment before cutover, including a live transaction with a real refund where payments are involved. Commerce migrations get extra scrutiny here, which is why we scope them alongside the wider ecommerce build rather than as an afterthought.
What we do if something goes wrong
Occasionally something does. A third party service behaves differently under production load, a redirect rule interacts badly with a legacy pattern, or an integration partner has an undocumented allowlist. The difference between an incident and a disaster is whether a rollback path was prepared.
The rest of the answer
We keep the previous environment intact and reachable for at least a fortnight, hold DNS TTL low through that window, and maintain a written runbook naming who makes the call to roll back and on what threshold. Backups are taken immediately before cutover and test restored beforehand, since an untested backup is a hope rather than a plan. Ongoing, most clients place the new environment on managed hosting with monitoring so the first person to know about a problem is us rather than a customer on the phone.
How we scope it
Four ways to scope your Website Migration project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Website Launch
A credible site, built properly, live sooner
Fixed written quote, agreed before work starts
- Complete URL inventory with traffic and link data
- Migrate, redirect or retire decision for every URL
- Tested one to one redirect map
Website Growth
A site that has to sell or integrate with something
Fixed written quote, agreed before work starts
- Everything in Website Launch
- Content and data migration with reconciliation report
- Integration and payment testing in the new environment
- DNS, certificate and email routing plan
Website Platform
A large site, or one built around your operation
Fixed written quote, agreed before work starts
- Everything in Website Growth
- Written cutover runbook with rollback thresholds
- Pre cutover backup with a verified restore
- Two weeks of post migration monitoring and a closing report
Website Care
Keeping it fast, patched and improving
Rolling monthly, quoted in writing
- Hosting, patching, backups and uptime monitoring
- Content and design changes as you need them
- Core Web Vitals watched, not assumed
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Will the site be down during the migration?
It should not be. The new environment is fully built and tested before anything is switched, DNS TTL is lowered in advance so the change propagates in minutes, and the old environment stays running until traffic has moved. Visitors mid session may finish on the old site and start their next visit on the new one, which is invisible to them. We schedule cutover at your quietest hour regardless.
Can you migrate us off a platform we no longer have full access to?
Usually. If the site is publicly reachable we can crawl and reconstruct content, and many platforms provide an export even on a lapsed plan. It is harder for customer records and order history, which sometimes must be requested from the provider under your rights as the data owner. Tell us early, because the retrieval path can take longer than the migration itself.
Detail and edge cases
How long does a website migration take?
Typically 2 to 5 weeks for a like for like move where the destination is already built. Inventory and redirect mapping take the first week, migration runs and testing the next, then cutover. Commerce migrations with customer and order history need longer because reconciliation matters more. Consolidating multiple sites into one takes longest, since the content decisions involve people rather than scripts.
What does a migration cost?
It scales with the number of URLs, the amount of non page data such as customers and orders, how many integrations must be reconnected, and whether the destination already exists or needs building. A small brochure site moving hosts is a modest job. A commerce replatform with fifteen years of order history is a project. We inventory first, then send a fixed written quote.
Who holds the accounts and credentials afterwards?
You do throughout. Hosting, DNS, certificates, payment gateways and third party services are all registered to your business with your billing details, and we work with access you grant and can revoke. During the project we produce a credential register so your team knows what exists and who controls it, which is usually the first time some organisations have had that written down.
What happens to our email when we change hosting?
Nothing, if it is handled deliberately. Email is controlled by DNS records that are separate from the ones pointing at your website, and problems occur when a provider moves nameservers without carrying those records across. We record every existing record before touching DNS, reproduce them exactly on the new configuration, and verify mail delivery after cutover as part of the checklist.
Related services
Planning a platform move?
Tell us where you are now and where you need to be. We reply within one business day with a migration plan outline and a fixed written quote.