Few backup migrations happen in a single weekend. New backups can be pointed at a new target in an afternoon, but the restore points already sitting on the old one carry their own retention, and the organization still needs to be able to recover from them. For weeks or months, sometimes years, the estate runs two backup targets side by side. That period is where most migration problems appear, not at the moment of cutover.
Running two targets is not just running one target twice. It changes how jobs are scheduled, how capacity is counted, how restores are found and how the old system is retired. Each needs a decision made in advance rather than discovered during an incident.
There are two ways to deal with existing restore points during a migration. They can be copied to the new target, or they can be left on the old one until they expire. Copying preserves a single place to restore from, but can take a long time for a large estate, may require reading every restore point back in full, and in some backup software resets the chain structure. Leaving them in place is simpler, but means the old target has to stay running and supported until the longest retention ages out.
Most migrations use a mix: short-term restore points are left to age out, and the small number of long-term ones that must be kept are copied. Preserving older restore points during a migration covers that choice in detail. Either way, there is a period when both targets hold restore points the organization depends on.
| Area | What changes | What to decide in advance |
|---|---|---|
| Job configuration | New jobs write to the new target, old chains remain on the old | Whether to start fresh full backups or seed from existing data |
| Capacity | The new target fills while the old one drains slowly | The new target's size at the point the old one is retired |
| Restores | The right restore point may be on either system | How operators find it quickly during an incident |
| Monitoring | Two systems to watch, one with diminishing attention | Who owns the old target's alerts until it is retired |
| Security | Two sets of credentials, two attack surfaces | Whether the old target keeps the same protections to the end |
The new target does not reach steady state on the day of cutover. It fills as new restore points accumulate, and only reaches its long-term size once a full retention period has passed. Sizing it for the steady state is correct, but the first full backups written to it can land as a burst, since every job starts a new chain at roughly the same time. Staggering the first full backups across several nights avoids a capacity spike and keeps the backup window from overrunning in the first week.
The old target, meanwhile, does not free space evenly. Daily restore points age out quickly. Weekly, monthly and yearly ones remain. An appliance that holds seven-year monthly restore points will stay mostly full for a long time after new writes stop.
The most common failure during a parallel period is not a failed restore but a slow one, caused by operators looking in the wrong place. A request for a file from three weeks ago may be on the new target if the migration started a month ago, or on the old one if it started last week. Backup software that catalogs both targets in one console handles this well. Where the old target is cataloged separately, a simple written rule tied to the cutover date saves time when it matters.
Restore testing has to cover both systems for the same reason. A restore test that only touches the new target says nothing about whether the old one can still deliver, and the old one is the system receiving less attention. Choosing representative workloads for restore tests applies to both sides of the overlap.
An old backup target in its final months is an attractive target for an attacker. It holds real restore points, it is often running older software, and it no longer receives the same care as the production system. If it was immutable, that immutability needs to hold until retirement. If its support contract ends during the overlap, the team needs a plan for what happens if it fails, since an unsupported appliance with no spare parts can become unrecoverable in a single disk failure. Questions to settle before a Veeam repository migration covers the software side.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. As the new side of a migration, it is added to the backup software as an S3 compatible repository, and new jobs or backup copy jobs can be pointed at it while the existing target continues to hold its restore points. S3 Object Lock applies immutable retention from the first object written, so the new target is protected during the overlap rather than after it.
It scales from roughly 50 TB to 8.5 PB by adding capacity to the existing deployment. That matters for the overlap, since the new target can be brought up at a size that suits the first months and grown as the old one is drained, rather than being bought at its final size on day one.
A parallel period without an end date tends to last indefinitely. The old target should have a written retirement date, calculated from the longest retention it still holds, and a short list of conditions for reaching it: all required long-term restore points copied or expired, a final restore test passed, and the catalog cleaned of references to it. When those are met, the old system is switched off and its media handled under the organization's disposal policy, rather than left running in a corner of the data center for another year.