Ask a company that has just finished an ERP implementation where the schedule went, and the answer is rarely configuration. It is the data: article masters with three conventions layered on top of each other, customers who exist four times, stock figures that have been quietly wrong for years, and open items nobody can explain.
None of that is visible when the plan is written, because the plan assumes the data describes reality. It usually describes a decade of workarounds. And in manufacturing, most companies are not installing their first system but replacing one: across the EU, 57.6% of manufacturing enterprises with ten or more employees already used ERP software in 2025, according to Eurostat. Every one of those replacements inherits the old system's data, and its habits.
Below: why migration overruns, what Swiss law requires you to keep, the details that catch Swiss companies out, and a sequence a team without a data department can run.
Why does data migration overrun so often?
Because the effort is not in moving records, it is in deciding what they should be. Every duplicate customer, obsolete article and unexplained open item needs somebody with authority to say what the correct value is, and those decisions arrive one at a time from people who have other jobs. The extract, transform and load step itself is usually a few days of work.
Plan the calendar around the decision rate, not the record count. A migration with 40,000 records and 200 open questions is a 200-question project. If the people who can answer those questions close ten a week between customer calls, the migration takes twenty weeks, whatever the tooling.
The second reason is timing. Most plans put data last, after configuration, because the target structures are not final until then. That means the first honest look at data quality arrives when the go-live date is already fixed and announced. The overrun is not caused by the data being bad. It is caused by discovering how bad it is with no time left to act.
The third is that migration sits between two owners. The implementation partner owns the load tooling; the business owns the content. Each assumes the other has the harder half. In the programmes we have reviewed, the gap between those two assumptions is where most of the unplanned weeks come from, and it is the same decision latency that sets the pace of the whole programme, described in why ERP programmes stall.
The four categories, in the order they hurt
Not all data deserves the same treatment. Four categories behave differently, and they load in a fixed order because each one references the layer beneath it.
Master data: customers, suppliers, articles, bills of material. Highest value, worst condition, and the only category where cleaning is unambiguously worth it. Cleaning happens in the source system, by the people who own the records, starting long before the new system exists.
Open transactions: orders, invoices, stock. Must be exact at cut-over, which makes them a logistics problem rather than a data-quality one. The answer is a freeze window and a reconciliation, not a transformation script.
History: closed years. This is where scope quietly doubles. Migrating five years of transactional history into the new system is expensive, slows the target, and is almost never needed. Keep the old system readable, or export to an archive, and migrate balances only.
Configuration-adjacent data: tax codes, units, price lists, account mappings. Small volume, disproportionate blast radius. One wrong tax code discovered in month two is worse than a thousand missing article descriptions.
How much history should you actually migrate?
Balances plus the current year, in most cases. Swiss law requires accounting records to be kept for ten years and to stay readable, but it does not require them to live inside the new ERP. A documented, read-only archive of the old system, or a complete export with its documentation, meets the obligation at a fraction of the cost of migrating closed years.
The rules are specific enough to plan against. The Code of Obligations, Art. 958f requires accounting records and vouchers to be retained for ten years from the end of the financial year, on paper or electronically, provided they can be made readable again at any time. The ordinance on keeping and retaining accounts, known as GeBüV, addresses migration directly: data may be moved to other formats or media if completeness and accuracy are preserved and the records remain available and readable, and the transfer itself has to be logged, with the log kept alongside the data.
VAT adds its own layer. The Federal Tax Administration expects an audit trail from each voucher through the accounts to the VAT return and back, available at any time. Its guidance on VAT audits sets retention at ten years after the end of the tax period, and twenty years for records relating to immovable property. If an inspector needs to see records held electronically, you must provide the means to read them and explain how they work.
Three practical consequences follow. First, decide early whether the old system stays readable or is exported, because keeping a licence and a server alive for ten years has a running cost, and exporting has a documentation cost. Second, whoever runs the archive needs the instructions that explain it: GeBüV requires the procedures, responsibilities and programs used for the books to be documented and kept as long as the records themselves. Third, write the decision down, with your auditor's agreement, so it is not reopened every month by someone who would feel safer with everything migrated.
How long does an ERP data migration take?
For a company of 30 to 150 people with one legal entity, three to six months of elapsed time is a typical observation in the programmes we have reviewed, measured from the first data profile to the cut-over load. Almost none of it is technical. It is the time the owners of the data need to make and record a few hundred decisions about what each record should be.
What changes with size is the number of people who must agree. In a 25-person distributor, the managing director and the bookkeeper settle most questions in a weekly hour; the constraint is that both are also running the company. At 200 people, master data is spread across purchasing, sales, production and finance, each with its own conventions, and the constraint becomes agreement between departments.
Two things shorten it reliably. Starting the cleanup before the new system is chosen, since the old system is where the cleaning happens anyway. And running trial loads early, which turns a vague worry about quality into a list of specific errors with names next to them.
The Swiss details that catch migrations out
Most migration problems are universal. A few are specific to Switzerland, and they surface late because they live in fields nobody looks at during selection.
Addresses now have to be structured. The QR-bill, which replaced Swiss payment slips on 1 October 2022, has permitted only structured addresses since 22 November 2025, with the address split into separate elements. The Swiss Payment Standards for bank payment files move the same way: SIX states that payment orders using an unstructured address must carry an execution date before 14 November 2026. A customer or supplier master where street, number and town sit in one free-text line has to be split before it is loaded. That is work for people rather than a script, because the free text is rarely consistent.
Tax codes span a rate change. The normal VAT rate is 8.1%, following the increase on 1 January 2024. Any open item or history you migrate from before that date carries the old rates, so the tax code mapping needs both, and the VAT reconciliation has to show they land in the right return.
Records have to stay provable. The tax administration's rules for electronic business records require proof of origin and integrity for VAT-relevant data, on paper or electronic, and treat that proof as given when the principles of proper bookkeeping are followed. An archive that someone can quietly edit fails that test.
Languages multiply descriptions. Article texts in German, French and Italian, or in German and English, turn every description into several fields. A cleanup that fixes one language and forgets the others produces customer documents in two versions.
What the sequence should look like
| Stage | When | What it produces |
|---|---|---|
| Profile the source | Before vendor selection | How bad it actually is, in counts |
| Assign ownership | Immediately after | One named person per data domain |
| Clean in the source | Continuously, from week one | Value even if the project is cancelled |
| First trial load | As early as the target allows | The real error list, not an estimate |
| Repeat loads | Every two to three weeks | A falling error count you can chart |
| Reconciliation | Each load | Signed off by finance, not by IT |
| Cut-over load | The freeze window | A rehearsed procedure, not a first attempt |
The item that most often gets skipped is the early trial load. Teams wait until the configuration is finished, which means the first honest picture of data quality arrives with no time left to act on it. Load badly, early, on purpose.
Each loop ends with a number that can be charted: records rejected, balances that do not match, open items without an owner. A falling line is the only progress report a migration needs. A flat one after three rounds means the decisions are not being made, and no amount of tooling will fix that.
The rule that saves small teams
Clean in the source system, not in the migration. Cleaning inside the transformation means the fix exists only in a script that runs once, the old system stays wrong during parallel running, and nobody else can see or verify the work.
Cleaning in the source means the improvement is real immediately, your own people do it in their normal tools, and if the programme slips a quarter you still keep the benefit. For a company without a data team, that difference decides whether the work gets done at all.
What "clean" means is narrower than people fear. It is not perfect data. It is data good enough for the processes that run on day one: every active customer once, every active article with a unit, a tax code and a valid supplier, every open item explained. Articles not sold for three years and customers not invoiced since before the pandemic do not need cleaning. They need a decision to leave them behind, which is the fastest cleanup there is.
The same discipline pays off later. Consistent article codes are what make forecasting possible, as set out in demand forecasting without a data science team, and they are the first of the data foundations an SME needs before AI. For an industrial company connecting its machines, the article and bill-of-material master is also what machine data has to be matched against, which is why Industrie 4.0 projects tend to start with the same cleanup.
A worked example: a 70-person machine builder
Take a hypothetical 70-person machine builder moving from an ageing ERP to a current one. The numbers are illustrative, chosen to show the mechanics rather than drawn from any client.
The first profile finds 9,000 article records, of which 3,500 have moved in the last three years. There are 1,800 customers, around 200 of them probable duplicates, and the address sits in a single free-text field. Open purchase orders include 60 that nobody recognises.
The team migrates only the active articles plus anything on an open order or a live bill of material. The head of purchasing owns supplier and article data; the head of finance owns customers and open items. Duplicates are merged in the old system over six weeks, between other work. Addresses are split by the sales back office, starting with the customers invoiced most often. The 60 unknown purchase orders are closed or confirmed with suppliers, one call at a time.
Trial loads start in week eight and repeat every three weeks, and the rejection list shrinks with each round. Closed years stay in the old system, switched to read-only, with a short document describing how to retrieve a voucher and who is responsible for the archive. Cut-over happens over a weekend after a freeze on goods movements, and finance signs off a balance comparison it has rehearsed three times.
Nothing in that sequence needs a data team. It needs two named owners, protected hours and the willingness to leave records behind.
Who signs it off
Finance reconciles balances. Operations confirms stock and open orders. Neither signature belongs to IT, and neither should be given on a summary. It should be given on a comparison the signer can reproduce.
If you are still choosing a system, profile the data during selection rather than after it, as set out in ERP selection for the Swiss mid-market. If you are still deciding whether to move at all, the signals are in when a small company actually needs an ERP, and the budget conversation is easier with ROI measured before you fund it.
Our ERP consulting practice treats migration as the first workstream rather than the last, because it is the one that sets the date.
Sources
- Eurostat — E-business integration, Statistics Explained, ERP use by economic activity, 2025
- Fedlex — Swiss Code of Obligations, SR 220, Art. 958f: ten-year retention, records readable at any time
- Fedlex — Geschäftsbücherverordnung (GeBüV), SR 221.431, Art. 4, 6 and 10: documentation, availability and data migration
- Federal Tax Administration (ESTV) — MWST-Kontrolle, audit trail and retention periods
- Federal Tax Administration (ESTV) — Elektronischer Geschäftsverkehr, proof of origin and integrity
- Federal Tax Administration (ESTV) — Swiss VAT rates, current normal rate
- Federal Tax Administration (ESTV) — Erhöhung der Steuersätze per 1. Januar 2024, the 2024 rate change
- SIX — QR-bill, structured addresses since November 2025
- SIX — ISO 20022 and the Swiss Payment Standards, transition deadlines for payment files
Related reading
- Why ERP programmes stall in Swiss mid-market companies
- ERP selection for the Swiss mid-market
- When does a small company actually need an ERP?
- Is your data ready for AI? The five foundations an SME actually needs
- ERP consulting
Working on this right now?
Tell us where you are in two questions. A consulting partner reviews every enquiry within 2 business days.
