Move over without
stopping work.
A phased path from spreadsheets or fragmented tools onto Trivena: map master data, load into a test Site, configure how you work, then cut over on a clean date.
Test Site first · Phased rollout · Your data exportable at any time
Migrations fail for boring reasons
Almost never because the new system lacked a feature. They fail because someone tried to move eleven years of history and six departments at once, or because two people disagreed on what counts as a customer and nobody noticed until go-live.
So we do the opposite: narrow first phase, real data in a test Site, explicit decisions about history, and a cutover date everyone can see coming.
Six steps, in order.
- 01
Scope the first phase
Pick one department and one clear outcome, such as invoicing off spreadsheets or the support queue into Helpdesk. A narrow first phase is what makes the second one easy.
- 02
Map your data
We walk through your master data with you: customers, suppliers, items, employees, chart of accounts. Fields that have no home in the standard model become custom fields.
- 03
Load into a test Site
Data goes into a separate Site first. You check totals, spot the import quirks, and adjust the mapping without touching anything live.
- 04
Configure how you work
Roles, permissions, approval chains, numbering series, print formats, and the views each team needs. This is configuration in Desk, not development.
- 05
Cut over on a clean date
Open transactions and opening balances are loaded as of the cutover date. History that only needs to be readable stays where it is or comes in as reference records.
- 06
Add the next app
Once phase one is boring, switch on the next application in the same Site. Users, permissions, and customer records are already in place.
What comes across.
The decisions below account for most of the effort in any migration, and most of the risk.
- Master data
- Customers, suppliers, items, price lists, employees, and the chart of accounts. This is what we always bring, because everything else references it.
- Open transactions
- Unpaid invoices, open orders, current stock, leave balances, and unresolved tickets. These come in as of the cutover date so day one in Trivena is accurate.
- Opening balances
- Closed periods are loaded as balances rather than replayed as documents. Your books start correct without importing years of journal entries.
- History you need to read
- Past invoices, closed tickets, or old deals can be imported as reference records, or left in the old system in read-only mode. We help you decide which is honestly worth the effort.
- What to leave behind
- Duplicate records, dead custom fields, statuses nobody uses, and workflows that exist because a tool required them. A migration is the cheapest chance you will get to drop them.
Where companies migrate from.
From spreadsheets
The most common starting point. Structured sheets import cleanly; the real work is deciding on one definition of a customer and one item list.
From point-solution SaaS
Most tools export CSV or offer an API. We map their fields onto the Trivena data model and keep the old system readable during the transition.
From an older ERP
Master data, open transactions, and opening balances are extracted and mapped. Closed periods stay as balances rather than being replayed.
From another Frappe-based system
If you already run on the same underlying framework, migration is considerably shorter, because the data model concepts line up directly.
From paper and email
Genuinely common in operations-led companies. Here migration is mostly configuration plus a first clean data entry pass, and the gain is immediate.
Partly, and on purpose
Keep a specialised tool you rely on and connect it over REST or RPC APIs while the rest of the company moves.
Migration questions.
No. Data is loaded and validated in a separate test Site while your current system stays live. The cutover itself is a defined date, not an outage.
A single-app phase with reasonably clean data is typically weeks, not quarters. Multi-department rollouts are planned in phases. Data quality drives the timeline far more than software does.
Usually you should not. Bring master data, open transactions, and opening balances. Decide deliberately how much closed history is worth importing versus keeping readable elsewhere.
It is collaborative. You own decisions about your data and process; we help with mapping, imports, and configuration. Agencies and implementers can also run the whole project on Trivena Cloud.
Then say so early and we plan for it. Duplicate customers and inconsistent item codes are normal. Cleaning during mapping is far cheaper than cleaning after go-live.
Yes, and that is exactly what the test Site is for. You see your own data in Trivena and check the numbers before any cutover decision.
Keep it read-only for as long as your retention rules require, or export an archive. Either way, your data in Trivena is exportable over the API at any point.
Plan your first phase with us.
Tell us what you run today and where the pain is loudest. We'll propose a scope that is small enough to actually finish.
Or email cloud@tynktech.nl