Content migration and decommissioning
Twenty years of content moved in waves, with the legacy repository actually switched off at the end — which is the part that most migrations quietly drop.
What a migration that finishes looks like
Content inventory and profiling
What exists, how old it is, how much is duplicated and what has not been opened in years — before any decision about what moves.
Migration in waves by category
Moving by content category rather than by department, so each wave can be validated against a clear expectation and stopped if it is wrong.
Retention applied during the move
Retention and classification applied as content moves, so the new system starts governed instead of inheriting an ungoverned heap.
Both systems readable during cutover
A period where the old repository is readable but no longer written to, which removes most of the risk from any single wave.
Link and reference rewriting
Links in documents, intranet pages and applications rewritten, because broken references are what drive people back to the old system.
Decommissioning the legacy system
A planned switch-off with a date, an owner and an archive — the step that turns a migration into a saving.
Don’t see your challenge here? Talk to us about your project
Everyone agrees the old repository has to go; nobody wants to own switching it off
Migrations stall at ninety per cent. The bulk moves, a long tail remains, the old system stays readable just in case, and five years later it is still running, still licensed and still backed up.
Planning the switch-off from the beginning — naming the date, the owner and what happens to the residue — is what changes that. It also disciplines the earlier decisions, because content nobody will claim is content nobody needs to move.
- Profiled first
- Age, duplication and usage measured before moving.
- Waves by category
- Each wave validated against a clear expectation.
- Governed on arrival
- Retention applied during the move, not after.
- Read-only interim
- Old system readable, not writable, during cutover.
- Links rewritten
- References fixed so nobody goes back.
- Switch-off planned
- A date and an owner from the start.
Moving knowledge without waiting for a migration to finish
The SINTEF search work took the opposite route deliberately: rather than blocking on a consolidation, knowledge across legacy systems was made findable where it stood. That is often the right answer — and where migration is still warranted, the search analytics show precisely which content justifies the effort.
Common questions
How long does a migration take?
It depends on how much you decide not to move. Profiling usually shows a large share is duplicated or obsolete, and the discussion about what to retire has more effect on the timeline than any technical choice.
Can we keep the old system as an archive?
You can, but it should be a deliberate decision with a cost attached rather than the default outcome. Where an archive is genuinely needed, a read-only export is usually far cheaper than keeping the original platform licensed and patched.
What if a wave goes wrong?
The old repository stays readable and unchanged during cutover, so a wave can be re-run. That is why we move by content category — the blast radius of any single wave stays small and verifiable.
Let's talk about your information estate
Tell us what people cannot find today and which system nobody wants to own. We will come back with an honest read on whether the answer is search, governance or migration — and what a realistic first phase looks like.
