A Brisbane showroom came to me part-way through a website rebuild. A design agency had built them a smart new WordPress site, the old e-commerce platform was still running the live site, and the monthly bill for that old platform was about $200. The instruction was reasonable enough: get the new site up, and cancel the old platform as soon as possible.

I did not cancel anything that week. Here is why, and what a proper migration audit turns up before you switch anything off.

The website was living on the platform they wanted to cancel

The first thing I check on any migration is DNS, because DNS is what actually decides which server the world reaches.

The domain's apex record pointed straight at the old platform's servers. The www record pointed at the platform too. The new WordPress build was not connected to the domain at all yet, because it was not finished.

So cancelling that subscription would not have saved $200. It would have taken the company's website offline, that week, with no warning, and the new site was not ready to take over. The saving they were picturing was real, but it lands at cutover, not before.

That is a five-minute check that avoided a self-inflicted outage. It is also the most common way I see businesses hurt themselves during a replatform: switching off the thing that is still doing the job.

Three more things the same check turned up

Once you are reading DNS properly, you may as well read all of it.

The email was on the same domain. Mail was running through Google Workspace, on records that sit alongside the website records. Website migrations break company email surprisingly often, because someone tidies up the DNS while pointing the domain at the new host. Those mail records were marked do-not-touch before any work started.

The DNS was not where anyone thought it was. The team believed the domain was managed at one provider. It was actually delegated to a different one entirely. Finding that out at cutover, on the day, with the site half-moved, turns a planned twenty-minute change into an afternoon of hunting for account access.

The card on file had expired. The old platform's billing card had expired a few months earlier. Nobody had noticed, because nothing had failed loudly yet. A business relying on the old platform to stay up until cutover very much wants that card to work.

There was one more finding that changed the plan: most of the subscription was billed annually and already paid. Cancelling early would have forfeited the remainder rather than saved it. The honest advice was to keep paying for a service they had already bought, finish the migration properly, and cancel at renewal. I put that in writing, because it was the opposite of what had been asked for.

Then there was the site itself

With the infrastructure understood, I went through the new build page by page.

The redirect map is the part that decides whether you keep your search rankings. The plan I inherited listed about 18 addresses to redirect. The live site's own sitemap listed around 119 that were indexed and reachable. Most collapsed neatly into a handful of rules, but six real articles and two live pages had no home on the new site at all. Miss those and you do not notice for a month, and then you notice in the traffic.

Two of them were the contact page and the about page. Both live, both indexed, both returning "not found" on the new build. The contact page was also where every booking came from, through a paid appointments add-on that only existed on the old platform. That is not a redirect problem, it is a "the business stops receiving enquiries" problem, and it went to the top of the list.

Three project pages had no content whatsoever. Not thin content, not badly styled content. The pages existed, they had a title and a header photo, and the body was empty. They had been published that way. The original write-ups, the material specifications, the builder and designer credits and every project photograph were still sitting on the old platform, which was the same platform we were about to cancel.

That is worth sitting with. Cancel the old site before the content audit, and that material is simply gone.

The check nobody asks for

While going through the project photography I ran a rights check, which is a fancy way of saying I opened every image properly.

Every photo in two of the galleries carried a watermark from the agency that had shot them for a property listing. Several also had a for-sale sign in frame, with a name and mobile number legible at full size. They had been supplied in good faith and published without anyone viewing them at full size.

Nothing was deleted. I flagged it, showed exactly which images and why, and left the call to the client. They chose to keep them, which is perfectly reasonable for a showroom that wants its work shown. The point is that it became a decision made with the facts, rather than something discovered later by whoever owns the photos.

What actually got built

The audit is the part people remember, but most of the work was the unglamorous part:

A private staging copy of the site, password-gated and set to no-index, so the client reviews real pages instead of screenshots and nothing competes with the live site in search.
A production server set up properly: current LTS operating system, TLS certificates, firewall, automatic security updates, key-only SSH access.
Nightly off-site backups that pull from the server to storage the server itself cannot reach or delete. Database and files, kept for a month, restore-tested rather than assumed.
Every internal link and media reference converted so it no longer hard-codes the domain, which means moving the site between environments stops requiring a database rewrite each time.
The defects in the delivered build fixed and documented, from a broken phone link and a wrong phone number through to the site name still carrying the developer's placeholder text.

None of that is exciting. All of it is the difference between a website you own and a website you are renting from whoever built it.

What to take from this

If you are moving a website between platforms, or you have just had one built, the questions worth asking before anything is switched off are simple:

Where does the domain actually point right now? Not where you think. Look it up.
Where does the email point? Confirm it before anyone touches DNS.
What is currently indexed? Pull the live sitemap and count it. Compare that with the new site's pages. Every address that disappears needs somewhere to land.
Where do enquiries actually come from? If it is a form or a booking tool on the old platform, its replacement needs to be live before cutover, not after.
What exists only on the old platform? Copy, photos, reviews, articles. Get it off before you cancel anything.
Is the old bill actually saveable? Prepaid annual plans do not refund. Sometimes the right answer is to keep paying until renewal.

Any competent person can move a website. The value is in the fortnight before the move, while the things that would have gone wrong are still cheap to fix.

Why me

I am a Brisbane-based IT partner for small and medium businesses, and I do not outsource. When I take on work like this I audit what is actually there before I touch it, I write down what I find, and I tell you when the thing you have asked for is a bad idea, including when that is inconvenient for me.

If you have a website being rebuilt, a platform bill you are trying to get rid of, or a site somebody else built that you would like a second opinion on, book a free 15-minute chat and I will tell you plainly what I would check first.

Shared anonymously. Specific findings differ from site to site.