A cutover is not survived. It is rehearsed
Most companies stay in a system they dislike for one reason: the fear of moving outweighs the dissatisfaction. So migration into NG One runs as a procedure with artefacts rather than a weekend with everyone on the phone. Every step has an output you can see and sign, the trial migration runs before the real one, the numbers are compared through control totals, and going back to the old system is part of the plan from the start.
- Trial migration in isolation
- Control totals and sign-off
- Permanent code mapping
- Dry-run diff before commit
- Cutover rollback
- Parallel running
Why migrations break, and what changes that
Migrations rarely fail on the technology. They fail because a mapping decision was made verbally on a Tuesday evening, and nobody could reconstruct it afterwards.
The typical failure looks like this: the data moves across, the system goes live, and three weeks later somebody notices a customer's balance is wrong because two of their codes in the old system were merged into one, and the document explaining that no longer exists. Or the stock count does not agree, because stock was moved across in aggregate while the old system tracked lots. At that point there is no way to establish what was actually transferred, because the import was a script that did the job and left nothing behind.
NG One addresses this by making import a framework rather than a script. The mapping from source columns to system fields is a record that is saved, reused and kept permanently — the mapping from an old code to a new one is kept forever, so a year later any figure can still be traced to its original. Before anything is written, a dry run shows exactly what would be created, what would change and which row would fail, with an error per row rather than one sentence about failure. A repeated import does not duplicate, because the framework is idempotent by design rather than by luck.
Above that sits the cutover as a process. The trial migration runs into an isolated space where everything can break without consequence. Reconciliation compares the old and new systems through control totals — the trial balance, open customer and supplier items, stock value and quantity by warehouse and lot — and somebody signs those numbers before the cutover is confirmed. Rollback is not a panicked improvisation but a prepared step with a restore point defined in advance. The aim is that the move is an event you have already seen once, only without the consequences.
What you are moving from
Every source carries its own question. These are the ones we ask in the first meeting — before any date is agreed.
- Regional ERP
Pantheon
The most common source in the Serbian market and the system with the most accumulated history. The move is usually rich in data and poor in documentation about why the data is the way it is — so most of the work is not the transfer but the decision about what transfers at all.
- A chart of accounts with analysis grown into the account codes — the key decision is which analysis becomes a dimension in NG One and which stays an account
- Several years of history: we agree how much moves as transactions and how much stays in the old system as an archive for reference
- Registers with duplicates accumulated over years of work — cleaning and merging happen before migration and are mapped permanently
- Company-specific modifications and reports: catalogued as requirements and answered through configuration rather than transcription
- Global ERP
Microsoft Dynamics 365 Business Central
Technically the easiest source, because NG One shares the same dimensional posting model. The dimensions you already run are not translated into something else, they are mapped across — so the conversation is mostly about the local obligations BC never covered.
- Dimension sets map directly onto NG One dimensions — your reporting structure is not reinvented
- Posting groups and schemes translate into effective-dated posting rule configuration
- The local part that was probably outside the system or in an add-on — payroll, petty cash, travel orders, the goods record book, VAT records — moves into the core
- Customisations and extensions are catalogued: the goal is that after the move they are configuration rather than code
- Regional ERP
Calculus
Common in trade and distribution, with a strong goods side. In practice the move revolves around stock and price books: those are the figures a company knows by heart, and where a poor migration shows immediately.
- Stock by warehouse, with lot and expiry where they are tracked — moved line by line rather than in aggregate, otherwise the stock count can never be reconciled
- Price books and per-customer discount policy, with validity — moving into versioned price books
- Open customer and supplier items, linked to the document they came from wherever that link exists
- Packaging, returnable packaging and item declarations are catalogued separately, being the most frequent source of a stock count discrepancy
- Regional ERP
BizniSoft
Widespread among small and mid-sized companies and accounting firms. The data is usually tidy and fits the templates, so the migration is quick — but the attention shifts to how the work is organised.
- Standard registers and the chart of accounts map well through templates, often without special mapping
- If you work through an accounting firm, we define who enters what after the move and with which rights — a decision about process, not data
- Dimensions are introduced immediately, because in smaller companies the analysis usually lived in a spreadsheet beside the system
- Multiple legal entities merge into one account with separate numbering instead of two installations
- Cloud accounting
Minimax
Common in companies that kept accounting in the cloud and goods and production somewhere else. The migration is therefore twofold: accounting moves across, and everything that has lived outside a system until now enters one for the first time.
- Chart of accounts, ledgers and open items move through templates without much mapping
- Goods handling with stock enters the same system for the first time — opening stock is gathered by a physical count, not by an export
- Working through an accounting firm and the split of responsibility after the move are defined at the start, as they change the licence scope
- What lived in a spreadsheet beside the system enters as a dimension or a document instead of staying beside it
- No system
Excel and paper
More common than anyone admits, and not the worst starting point. The data is usually accurate, because somebody looks at it every day, but it is not structured — so the work is in the structure, not the transfer.
- The template builder shapes a template around your spreadsheet, instead of you reshaping the spreadsheet around a template
- Duplicate partners and items surface during import, with an error per row and a merge suggestion
- Opening stock comes from a physical count at the cut-off date, because there is nothing to export — and that is the only reliable route
- Open items are entered from statements of account and bank statements, reconciled before the first period opens
- A Konis system
NG Operational
Our own system, so the mapping is a known quantity rather than an assumption: we analysed it file by file and recorded what carries over as a concept and what NG One does its own way. The business concepts move on; the architecture stays behind.
- Planning, procurement, contracting, sales, production, bills of material and the laboratory carry over as proven business concepts with their UX patterns
- The warehouse does not carry over: NG One has its own, with bin locations, directed picking and waves — stock has a single source of truth instead of several parallel tables
- Codes and documents are mapped permanently, with the business numbering convention retained
- What transfers and what does not was written into the plan before the migration — no negotiating scope along the way
The list is not closed. The procedure does not depend on the name of the system but on whether the data can be exported to a spreadsheet and whether somebody can answer why it looks the way it does — and the second is harder than the first.
Six steps
Every step has an output you can see before the next one begins. The date is agreed after the first step, not before it.
- Step 1
Analysis
We catalogue what exists, in what shape, and who owns it. Nothing moves here — here the decisions are made that cannot later be changed without re-posting.
- An inventory of sources: systems, spreadsheets, paper; the owner of each data set
- The dimension decision: which of today's analysis becomes which NG One dimension
- The history decision: what moves as transactions, what as opening balances, what stays archived
- The cut-off date and the list of data that must be cleaned before it
- Step 2
Mapping
Old codes get new ones, source columns get fields, and every decision becomes a record. The mapping is kept permanently — it is what explains, a year later, where a figure came from.
- A template per data set through the template builder, shaped around your spreadsheets
- Source columns mapped onto NG One fields, saved and reusable
- Permanent mapping from old code to new, including duplicate merges
- Cleaning and validation rules, agreed before the first import runs
- Step 3
Trial migration
The whole migration runs into an isolated space where a mistake is free. This step repeats as often as needed — each iteration is cheap precisely because it touches nothing.
- An isolated environment with your data, separate from production
- A dry-run diff before every write: what would be created, what would change, what would fail
- An error per row with its reason, instead of one message about a failed import
- Repetition until a clean pass; idempotency means a repeated import does not duplicate
- Step 4
Reconciliation
The old system's numbers are compared with the new system's, and somebody signs them. This is the step most often skipped and the only one that saves you afterwards.
- Control totals: the trial balance, open customer and supplier items, stock value and quantity by warehouse and lot
- A difference report explaining every item that does not agree
- Sign-off on the control totals: a named person confirms the figures are correct
- No sign-off, no cutover — that is a rule, not a recommendation
- Step 5
Cutover
The move at the cut-off date, to a plan already rehearsed by then. Rollback is prepared before the cutover begins, not invented when it is needed.
- Freezing entry in the old system and the final import at the cut-off
- The control totals checked again against production, not against the trial
- A defined restore point and the condition that triggers a rollback — agreed in advance
- Opening the period and releasing users in sequence rather than all at once
- Step 6
Hypercare
The first weeks after the move are part of the project, not a warranty period. Parallel running stops when the numbers agree twice in a row, not when the calendar says so.
- Intensified support with an agreed response time and named people
- Parallel running at an agreed scope until the first calculations and the first period close are confirmed
- Daily reconciliation of the key figures in the first week, then at an agreed rhythm
- A list of open questions with an owner and a deadline, instead of verbal promises
Duration depends on the state of the data, not the size of the company. A small company with an untidy register has a harder time than a large one that keeps its data in order — and that is the only honest forecast we can offer before the analysis.
What is guaranteed, and by what
A guarantee without a mechanism is a sentence. Each one here states exactly what stands behind it.
Control totals and sign-off
The cutover is not confirmed until the old and new systems agree and somebody signs that they do. The comparison runs across the trial balance, open customer and supplier items, and stock value and quantity by warehouse and lot.
A reconciliation report with differences per item; the sign-off on control totals is a record with a name and a date, not a verbal confirmation; without it the cutover does not proceed.
Cutover rollback
Returning to the old system is a prepared step with a defined restore point and a pre-agreed condition that triggers it. The rollback decision is taken against a criterion, not against the mood in the room at three in the morning.
The restore point and the trigger condition are recorded before the cutover; the old system stays in a state it can resume from until the agreed deadline; the procedure is rehearsed during the trial migration.
Parallel running
The move need not be a leap. At an agreed scope and for an agreed period the key flows can run in both systems, until the first calculations and the first period close are confirmed.
The scope of parallel running is defined during analysis because it costs; it stops when the control figures agree twice in a row — against a criterion, not a calendar.
A trial migration without consequence
The whole migration runs in an isolated space before it touches production, and repeats as often as needed. What you see on cutover day is something you have already seen once.
A separate environment with your data; a dry-run diff before every write; an error per row with its reason; an idempotent import that does not duplicate on repetition.
Permanent mapping of legacy codes
The link between an old code and a new one is kept forever, including duplicate merges. A year later, when somebody asks where a balance came from, the answer exists in the system.
The mapping is a record in the database, not a column in a spreadsheet that went missing after the import; searching by the old code still works after the move.
Your data stays yours
Excel export exists on every list, the API is open across all resources, and a complete data export is part of the termination procedure. Moving into NG One does not create a door that is easier to enter than to leave.
Export on every list, an API with an OpenAPI specification, a complete customer export that works even while an account is suspended; every export is recorded — who, what, when and at what scope.
What carries this procedure
Everything on this page rests on tooling rather than on a consultant's goodwill. These are the parts that carry it — ask to see each of them in a demo, with your own data.
The platform import framework
The template builder shapes a template around your spreadsheet, column mappings are saved and reused, validation returns an error per row with its reason, the dry-run diff shows the outcome before it exists, and the import is idempotent — repeating it does not duplicate. The same framework carries every register import in the system, so migration is not a side road nobody else travels.
Excel export on every list
Part of the enterprise table standard: every list exports what is on the screen, with the filters and columns you applied. Together with an API open across all resources and an OpenAPI specification, that is an exit guarantee rather than a convenience — the door in is no wider than the door out.
The migration and cutover package
Templates for partners, items, the chart of accounts, opening balances, open items and stock by lot; permanent mapping of legacy codes including duplicate merges; the trial migration in an isolated space; reconciliation with control totals and sign-off; rollback with a restore point defined in advance.
A guided cutover with a consultant
A small customer loads their own data through the templates — that is what the framework was built for. A larger one gets a guided process: a named consultant, a cutover plan with its rollback condition, and hypercare with an agreed response time.
How long does a migration take?
It depends on the state of the data, not on the number of users or the turnover. A small company whose register holds the same partner three times has a harder time than a large one that keeps its data in order, because the work is in the decisions, not the transfer. So we agree the date after the analysis rather than before it — a number quoted now would be invented, and we would both know it. What we can say in advance is the order: analysis produces the decisions on dimensions and history depth, mapping turns them into records, the trial migration repeats until it passes cleanly, reconciliation confirms it, and only then does a date mean anything.
What if the numbers do not agree after the migration?
Then the cutover does not proceed — that is a rule, not a recommendation. Reconciliation compares the old and new systems through control totals: the trial balance, open customer and supplier items, stock value and quantity by warehouse and lot. Every difference is explained per item, and a named person signs the control totals before the move is confirmed. If a difference appears after the cutover, there is the rollback, with a restore point defined in advance and a pre-agreed condition that triggers it. The decision to go back is then taken against a criterion, rather than by whoever is loudest in the room at three in the morning.
Do you transfer the entire history from the old system?
Rarely, and it is usually not in your interest. History splits into three parts and each is decided during analysis: the transactions that genuinely need to be in the new system because you work with them, the opening balances that carry the position at the cut-off date, and the archive that stays in the old system or in an export for reference. Moving ten years of transactions into the system you will work in also moves ten years of errors, duplicates and mappings nobody understands any more — and you pay for it twice, once during the migration and once in every report afterwards. The practical choice is usually the current year as transactions, prior years as opening balances, the rest as archive.
What is the hardest part of the move?
The dimension decision, and it is taken in the first week. The systems people move from typically hold analysis in the chart of accounts — the cost centre, the plant or the project ended up inside the account code because there was nowhere else. In NG One that is a dimension on the posting line, which means the analysis has to state which of today's analysis becomes which dimension and which stays an account. That decision governs how you will report for the next ten years and is the only one that cannot later be corrected with a setting — only by re-posting. Second hardest is the stock count by lot, for the same reason: stock moved across in aggregate cannot be decomposed afterwards.
Can we run both systems for a while?
You can, at an agreed scope and for an agreed period. Parallel running has a price — the same work is done twice — so the scope is defined during analysis rather than left to grow on its own. In practice the key flows run in parallel until the first calculations and the first period close are confirmed, and they stop against a criterion: when the control figures agree twice in a row. A date in the calendar is not a criterion, because that date slips precisely when the numbers do not agree — which is when parallel running is most needed.
What if our data only exists in spreadsheets?
That is not the worst starting point. Data in a spreadsheet somebody looks at every day is usually more accurate than data in a system nobody checks; the problem is structure, not accuracy. The template builder shapes a template around your spreadsheet instead of you reshaping the spreadsheet around a template, and duplicate partners and items surface during import, with an error per row and a merge suggestion. The one thing that cannot be exported is opening stock — it comes from a physical count at the cut-off date. That is work you have to do yourselves, and it is the only reliable route.
What if we are moving from NG Operational?
Then the mapping is a known quantity rather than an assumption. NG Operational is our own system; we analysed it file by file and recorded what carries over as a proven business concept and what NG One does its own way. Planning, procurement, contracting, sales, production, bills of material and the laboratory move on with their UX patterns, because they have earned it. The warehouse does not carry over: NG One has its own in the core — bin locations, directed picking, waves — so stock has a single source of truth instead of several parallel tables that disagree with each other. For you that means the scope of the migration was agreed before it started, rather than discovered along the way.
What should we prepare before the first meeting?
Three things, and all three are worth doing even if you never move. First, an export of your partner and item registers into a spreadsheet — half an hour with it shows how many duplicates you carry and how much cleaning is ahead, which is the bulk of any forecast. Second, the list of reports you cannot work without, each with the name of the person who actually reads it; that list describes your reporting more accurately than any process document, and the dimension decision falls out of it. Third, an answer to who owns which data set — who is entitled to say the item register is correct. With those three, the first meeting starts at the decisions rather than at the introductions.
Start with the analysis, not with a date
Book a review of your data with our team. We go through the sources, the dimensions you need, the depth of history and the state of your registers — and tell you what the work is, rather than how long you would like it to take.