A closer look at backup and recovery migration

The dangerous part of changing backup arrangements is not the new system. It is the two weeks when the old one is off and the new one has produced nothing you have restored from.

Businesses lose their recovery position in that gap more often than to an incident, and the gap is self-inflicted.

The method below assumes you are keeping both arrangements running for longer than feels necessary, and retiring the old one only after the new one has returned real data into your hands.

What to take away

Before anything: what the old arrangement actually holds

Write this down, because the answer decides how long the overlap has to be.

The last two are the ones that get skipped. A migration that leaves the old archive encrypted with a key nobody can find has converted years of history into noise.

The overlap rule

Run both arrangements at once for at least one full cycle of everything that matters: a month end, a payroll run, a quarterly report, and any process that touches data only occasionally. A week is not an overlap. It is a hope.

During the overlap the old arrangement is the one you would actually restore from. The new one is on trial. Treat it that way in writing, so that nobody assumes the switch has already happened.

Seeding the first full copy

The first complete copy is the slow one, and it is where migrations stall.

Ask the new provider how a first copy is seeded when the volume is large: over the connection, from a drive you send, or from an appliance in the building.

Then find out what happens to the business while that runs. A first copy saturating the office connection for four days is a decision somebody should make deliberately, not discover on Tuesday.

Treat a change of this size as a planned change against a recorded baseline, as in the United States National Institute of Standards and Technology's guide for security-focused configuration management. That is what keeps the fortnight from becoming a surprise.

Start it on a Friday. Watch it. If it has not finished by the time it should have, that is information about the arrangement, not a delay to be waited out.

Keys, and who holds them

Encryption keys, recovery passphrases and the account that administers the new console are three separate things, and all three need to exist somewhere outside the environment they protect.

Write down where each one lives, who else can reach it, and how you would recover it if the person who set it up were unavailable.

Then test: have somebody else retrieve one without help. One-person access is the same class of problem the pillar on identity and access describes for any other privileged credential.

Where the old arrangement's history is being kept, its keys have to survive the migration too, filed with a note saying which system they open.

Proving the new arrangement before you trust it

Do not accept a green dashboard as the end of a migration. Three proofs, in this order.

One file. Restore something from a week ago, open it, and confirm the contents. Time it.

One system. Restore a whole share or a whole machine into an isolated place. Time it. Compare the number against how long the business could actually be without it, which is a per-system answer already recorded in backup and recovery.

One restore performed by someone else. The person who configured it will find their own console easy. Somebody else finding it easy is the useful result.

Only after the third proof does the new arrangement become the one you rely on.

Retiring the old arrangement

That last row is the one that causes damage a year later, when someone follows a printed procedure to a console that was canceled. The plan is part of the arrangement, and the sequence it feeds into is the one in incident response.

When the migration is to or from an online platform

Moving backups of an online service to a different provider has an extra step: you are also changing what holds the standing access into your platform. Review that connection as an access grant rather than as a feature, remove the old one deliberately, and check that removing it did not also remove something else that was using it.

Where the migration is out of a platform entirely, an export is not a backup until you have read one back. What the platform keeps for you in the meantime, and for how long, is covered in cloud security, and the answer is usually shorter than people assume.

If the new arrangement fails the proofs

Go back. Keep the old one running, tell the new provider precisely which proof failed and what the timing was, and set a new date. A migration that rolled back once and succeeded on the second attempt is the ordinary case.

What is not ordinary, and what does real damage, is carrying on because the invoice has already been signed. The United States Cybersecurity and Infrastructure Security Agency's Cyber Essentials puts recoverability among the small number of things a business without a security team should get right, and a half-migrated arrangement fails that test in both directions at once.

Common questions

How long should the overlap really be?

Long enough for every periodic process to happen at least once, and long enough for all three proofs to pass. For most small businesses that is a month, and for anyone with a quarterly process it is a quarter.

Can we migrate the old history into the new system?

Rarely, and attempts to do it consume more effort than they return. The usual answer is to keep the old archive readable and let the new one build its own history, which is why the note about keys matters so much.

Do we need to keep old backups at all?

That depends on obligations specific to your industry, your contracts and your jurisdiction, and it is a question for your own legal advisers rather than for a general page. What a general page can say is that deleting the only copy of something before checking is irreversible.

The provider offers to run the whole migration. Should we let them?

Let them do the work and keep the three proofs for yourself, including the one performed by somebody who does not work for them. The measured restore time and the keys are the two things you cannot outsource, and the second is the reason the sequence in security foundations treats backups as a control rather than a purchase.