Move off a legacy portal without losing the history
Old portals are rarely replaced because the software is bad. They are replaced when the data, the logins and the integrations can move without a gap. This is how we plan that move.
Migration is scoped as its own workstream, with a dry run before anything is switched off.
Most migrations stall on the inventory, not the code
The old portal holds more than records: client logins, document versions, approval history, invoice references and the URLs clients have bookmarked. Miss one and the new system launches with a support queue attached.
We inventory every object before design starts, decide what moves, what is archived read-only and what is deliberately left behind, and write that decision down.
The cutover is then a checked sequence rather than a hope.
What moves
Five inventories, each with an owner and a check
Every object is counted at the source and counted again after transfer. A number that does not match stops the cutover.
Client and role data
Accounts, organisations, roles and permissions. Passwords are not copied; users set new ones through an invite or an identity provider.
Documents and versions
Every file, its versions and its metadata. Files are checksummed at the source and after transfer, so a truncated upload cannot pass.
Approval and audit history
Who approved what and when. History is imported read-only and stays searchable; it is not rewritten into the new workflow.
Financial references
Invoice numbers, payment references and balances. The new portal reads money from the finance system, not from a copied table.
Integrations and URLs
ERP, CRM, e-invoicing and payment connections, plus the old URLs that clients and search engines still use, redirected to their new equivalents.
How it runs
The cutover sequence
Five gates, in this order. Nothing is switched off before the gate before it has passed.
- 01
Inventory and freeze rules
Every object, its owner and its volume. We agree what can change during the migration and what is frozen.
- 02
Dry run on real data
A full copy into staging, with the checks run against it. Mismatched fields and orphaned files surface here, not on launch day.
- 03
Parallel run
The old and new portals run side by side for an agreed window. Your team works in the new one; the old one stays readable.
- 04
Cutover
Write access moves in a scheduled window. The old portal becomes read-only and the redirect map goes live.
- 05
Decommission
After the agreed retention period, accounts and data are removed from the old system and the credentials are revoked.
What goes wrong, and how it is caught
These five show up in almost every migration. Each one has a check attached to it.
- Duplicate clients
- Two records for the same company in the old system become two logins. The inventory includes a deduplication rule agreed before the dry run.
- Orphaned documents
- Files with no parent record are common. They are listed and either attached to a record or archived, never silently dropped.
- Identity mismatch
- An email that belongs to two accounts cannot be migrated as-is. These are resolved with you before cutover, not after.
- Broken bookmarks
- The redirect map covers every public URL, including document links sent by email. A 404 on an old invoice link becomes a support ticket.
- Reporting gaps
- Historical reports are preserved as read-only snapshots. New reports start from the cutover date, and the difference is documented.
Parallel run or single cutover
The answer depends on how many people log in and what breaks if they cannot.
Parallel run
Best for portals in daily operational use.
- The old portal stays readable
- Two systems to keep in step for the window
- The safer choice when money or approvals are involved
Single cutover
Best for low-traffic portals and clean data.
- One switch in one window
- No dual-running cost
- Requires a tested rollback
Questions buyers ask before a migration
How long does a portal migration take?
The migration runs inside the portal build, so the published 6–12 week band for a portal MVP applies when the data is clean. A parallel run or a large document archive adds a separate phase, quoted after the inventory.
Can you migrate from a portal you did not build?
Yes. We start with read-only access to the old system and its database or export. If the vendor will not provide an export, we work from the API or a screen-level export.
What happens to old documents?
They move with their versions and metadata, or they are archived read-only if they fall outside the retention policy. Nothing is deleted before the agreed retention period.
Do users keep their passwords?
No. Passwords are not copied between systems. Users receive an invite or sign in through the identity provider, and the old credentials are revoked at cutover.
Will old links still work?
Every public URL gets a redirect to its new equivalent, including document links sent by email. The redirect map is tested before the old portal is switched off.
Can we run both portals at once?
Yes. A parallel run keeps the old portal readable while your team works in the new one. The window is agreed in the plan, with an owner on your side.
Send the old portal shape and we will scope the move
Tell us what the old system holds, who logs in and which integrations it uses. We will come back with the inventory, the cutover options and a dated plan.
30 minutes, no obligation. If the old portal can be improved instead of replaced, we will say so.
