Handing Over Website Care to a New Provider Without Breaking Anything

The riskiest week in a website's life often isn't a hack

It's the week it changes hands between two care providers. A breach or an outage tends to get everyone's full attention immediately. A handover, by contrast, looks calm right up until it isn't — nameservers pointed the wrong way for six hours, an email system that quietly stops receiving mail because an MX record got dropped in the switch, a "final" backup that turns out to be three months old. None of that requires anyone to be careless. It requires two parties who each know their half of the process well, but who've never had to hand a live, revenue-generating website between them before.

This applies whichever direction you're moving. The same sequence protects a business leaving one provider for another, and it applies just as much to leaving JagaWeb as to arriving.

Before you give notice: what to have in hand

The mistake to avoid is giving notice to an outgoing provider before confirming you can actually get what you need from them. Ask for, and receive, the following while the relationship is still active and cooperative: full admin access to the hosting account and control panel, not just the CMS; the domain registrar login, or confirmation of who the registrant of record is if the domain sits elsewhere; a current export of the DNS zone file, showing every record — not just the ones the current site obviously needs, since old subdomains and forgotten MX or TXT records live in there too; a working copy of the codebase, including anything customised beyond an off-the-shelf template or plugin; a recent database export; and a list of every third-party service connected to the site — analytics, tag manager, forms, payment gateway, email delivery — with which account owns each one.

Getting all of this before notice is given, rather than after, changes the incentive structure entirely. A cooperative provider will usually hand these over either way, but requesting them while the contract is still live and the relationship is still working removes any ambiguity about whether they're obligated to help once notice is in.

Sequencing the transfer, not doing it all at once

The order matters as much as the checklist. A practical sequence looks like: confirm access to the domain registrar and DNS zone first, since that's the control point for everything downstream; take and independently store a backup and a code/database export before any other change happens; set up the new provider's environment and get the site running there, without touching the live domain yet; test it thoroughly on a temporary URL or via a local hosts-file override; and only then move DNS, ideally after lowering the DNS record's TTL (time-to-live) a day or two in advance, so that if something needs reverting, the change propagates back quickly instead of taking the full default TTL to unwind.

Doing this out of order — for instance, cancelling the old hosting account before confirming the new one actually works — is how a business ends up with a live site pointing at nothing for an afternoon.

Verify the backup you're inheriting, not just the one you're leaving

Any handover should include an actual restore test, not just a file marked "backup" sitting in a folder. That's a big enough topic to deserve its own process rather than a paragraph here — the short version is that a backup nobody has restored from is an assumption, not a safety net, and that assumption is worth testing before the old provider's access is gone and there's no one left to ask if something's missing from it.

DNS and email: the two things that break silently

Of everything in a handover, DNS and email are the two most likely to fail without an obvious error message. A DNS change that gets one record wrong doesn't usually throw an error — it just quietly sends some fraction of traffic, or some category of request, to the wrong place, and the first sign is often a support email arriving days later asking why the contact form doesn't work. Email deserves particular care because it's easy to overlook: MX records determine where a domain's mail actually gets delivered, and they're entirely independent of where the website itself is hosted. A provider migrating a site's hosting can, without meaning to, hand over a DNS zone file that's missing the MX and supporting SPF/DKIM records the business's email depends on, because from a website-hosting point of view those records look irrelevant. Cross-checking the full DNS zone — not just the records the new host's setup wizard asks for — against what was actually in use before is the only reliable guard against this.

The overlap period: running two providers on purpose

A clean handover usually isn't instant. Running the old and new environments in parallel for a short, deliberate overlap — new site live and verified, old one still reachable and unchanged as a fallback, DNS not yet cut over — gives room to catch a missed record or a broken integration before the fallback option disappears. The overlap doesn't need to be long. It needs to be long enough that if something's wrong, there's still an old, working version to point back to while it's fixed, rather than a live incident with no fallback.

What a professional outgoing handover looks like

From the departing side, a good handover looks less dramatic than a bad one, which is part of why it's easy to under-value. It means responding to access requests without stalling, handing over real admin credentials rather than a read-only view, providing whatever documentation exists about non-obvious customisations, and not treating the final invoice as leverage over releasing access the client is already entitled to. None of that requires a long relationship or a large team behind it — it requires treating access and data as things the client owns, which they do, regardless of who built or maintained the site.

The same standard applies both ways

None of this is specific to any one provider. A business switching to JagaWeb should expect to run through exactly this sequence with whoever they're leaving, and a business eventually switching away from JagaWeb should expect the same level of cooperation in return — full access, a verified backup, a documented handover, no artificial delay. That symmetry is really the whole point: a handover process worth trusting is one that works the same regardless of which direction you're moving in.

If ongoing care after a handover — monitoring, updates, a place to route fixes — is the immediate need, JagaWeb Care (RM450/month) covers routine maintenance, and Care + Changes (RM1,500/month) adds a working budget for content and fix requests once the new setup is confirmed stable. One option to weigh once the transfer itself is done, not before.