How to migrate without stopping work
Almost no migration fails because of a missing feature. They fail because someone tried to move eleven years of history and six departments at once.
The stories are remarkably consistent. A company decides to replace its tooling, scopes the project as everything, spends four months mapping data nobody will look at again, and goes live on a date that slips twice.
None of that is caused by software. It is caused by scope and by unmade decisions.
Narrow the first phase until it is boring
Pick one department and one outcome: invoicing off spreadsheets, or the support queue into Helpdesk. A first phase that finishes builds the confidence and the clean master data that make the second phase straightforward.
On Trivena this works because adding the next application is configuration rather than a new implementation. Users, permissions, and customer records are already in place.
Decide about history explicitly
- Master data always comes across: customers, suppliers, items, employees, chart of accounts.
- Open transactions come in as of the cutover date: unpaid invoices, open orders, current stock, leave balances, unresolved tickets.
- Closed periods come in as opening balances rather than replayed documents.
- History that only needs to be readable can stay in the old system, read-only, or arrive as reference records.
Validate in a test Site, not in production
Data goes into a separate Site first. You check totals, find the import quirks, and fix the mapping without touching anything live. Your current system keeps running the whole time.
The cutover then becomes a defined date rather than an outage.
Use the migration to drop dead weight
Duplicate customers, unused custom fields, statuses nobody sets, workflows that exist because an old tool demanded them. A migration is the cheapest opportunity you will ever get to leave those behind.
Cleaning during mapping costs a fraction of what cleaning after go-live costs.