A repository migration looks like a data movement problem and is usually a retention problem. If bandwidth were the only constraint, most environments could copy their backup estate over a long weekend. What actually decides whether the project runs for a weekend or a quarter is the history: whether it moves, whether the source will let go of it, and how long both repositories have to exist at the same time.
The plan that gets drawn on a whiteboard has three steps. Copy the data, repoint the jobs, decommission the old repository. Each step carries a condition that is rarely examined before a date is promised, and any one of them can turn a short project into a long one.
The questions below are worth answering before a schedule is written, since each one changes either the amount of work or the length of the overlap. None are answered by looking at the size of the existing repository.
There are two honest strategies. The first moves existing restore points so the old repository can be emptied. The second leaves them where they are, sends new backups to the new target, and lets the source drain as retention expires. Most migrations become a mix of the two without anyone deciding that explicitly.
Aging out in place costs almost no effort and a great deal of time. The overlap lasts as long as the longest retention still present on the source, which is normally a yearly GFS point rather than the daily chain. An environment with a twelve month GFS commitment is committing to twelve months of dual running unless something is deleted early.
Moving the history costs a copy of everything and requires that the copy arrive in a form the backup software still recognizes as a chain. A practical middle path moves the operational chain and leaves the long term points to expire, which is one of the tradeoffs worth working through when deciding what happens to older restore points.
If the source repository uses Object Lock, copying the data does not make the original removable. Each object stays locked until its own retain until date passes, whether or not a duplicate exists elsewhere. The old system cannot be powered off, repurposed or returned while any of those dates remain in the future.
That turns a storage decision into a scheduling constraint. The date the old repository can be retired is the latest retain until date in the source bucket, which is not the retention policy and has to be read from the objects. Whether anything can shorten it depends on the retention mode the bucket was created with.
Removing a job or a repository from the backup console does not help either. The configuration disappears, the objects remain, and the capacity stays consumed with nothing left to issue the deletes when the locks eventually lapse. That is the mechanism behind data that outlives the job that created it, and a migration is one of the most common ways to create it.
A repository is reached through an endpoint name, a bucket, a set of credentials, a certificate the mover has to trust, and a gateway or proxy that carries the traffic. If every one of those can be kept identical, a migration becomes a redirection. In practice at least the endpoint and the credentials change, and the certificate trust path changes with them.
Each detail is worth confirming rather than assuming. Which account the movers authenticate as, whether the certificate is issued by an authority the backup infrastructure already trusts, and which host carries the object traffic all decide whether the first run succeeds. These are the inputs that belong in planning an object storage repository in the first place.
| Question | Why it decides the timeline | What to confirm before a date is set |
|---|---|---|
| Does history move, or age out on the source? | Sets whether this is a copy exercise or a dual running exercise | The longest GFS retention still present on the source |
| Are source objects under a retention lock? | Determines when the old system can actually be removed | The latest retain until date in the bucket, not the policy |
| Same endpoint, bucket and credentials? | Decides repoint versus reconfigure for every job | Endpoint name, certificate trust chain, and the account the movers use |
| Are jobs repointed or recreated? | Recreation usually starts a new chain and a new full backup | Whether each job can keep its chain when the target changes |
| Can the old repository be used again for a week? | Sets how reversible the switchover is | That source retention and locks survive the cutover untouched |
| Who holds credentials and certificates? | Frequently the actual long pole on the plan | Expiry dates and the process for issuing replacements |
Changing the target of a job is not a neutral edit. In most configurations the next run writes a new full backup and begins a new chain, since the blocks an incremental would depend on are not present at the new target. When exactly that happens varies between versions and job types, so it is worth confirming in the deployment at hand.
The consequence lands on two graphs at once. The first run looks like a seeding run because it is one, and capacity on the new repository jumps to a full copy of the protected estate before deduplication across runs can help. Both are temporary, and both are easier to explain in advance than on the morning they happen.
Reversal is worth designing before it is needed. A switchover stays reversible only while the source repository is intact, still able to accept writes, and still holding a chain that has not aged past usefulness. If the first week goes badly, pointing the jobs back means resuming against an older chain, which may itself require a full. Doing one job first, waiting, then doing the rest is what keeps that decision small.
ARTESCA is object storage software used as a backup target, presented over an S3 compatible API, with immutability available through S3 Object Lock. When it is the destination, the migration questions become ordinary S3 questions: which endpoint, which bucket, which credentials, which certificate, and whether Object Lock is configured on the new bucket at creation time rather than later.
Because the software runs on infrastructure the customer operates, the overlap period is a local capacity question rather than a second subscription. Dual running consumes rack space, power and network ports until the source locks lapse, so the retirement date for the old system and the space it occupies are both things the team can see directly and plan around.
Sizing the new repository has to cover the new chain plus whatever history is moved plus the immutable copies that accumulate during the overlap. That combination is usually larger than the steady state figure, which is the same consideration that appears when weighing a refresh against an expansion.
Four facts belong on one page before any job changes target. The latest retain until date present in the source bucket, the GFS schedule that produced it, a per job decision on move or age out, and the connection details for the new repository including who owns the certificate. The first of those sets the earliest honest retirement date for the old system.
A rollback condition belongs on the same page, written as something observable. A named date, a restore test that must pass, or a backup window threshold that must not be exceeded are all workable. What matters is that it is agreed before the cutover, since afterwards the pressure runs entirely toward continuing.
The migration is then best run one job at a time, starting with something whose failure costs a conversation rather than a weekend, and with one successful restore from the new repository before the second job moves. Nothing on the source should be deleted until a restore from the new target has been performed and timed. That rule is worth writing down too, since it is the one most often broken to free space.