How to Migrate from 1C 7 to a Modern ERP
A practical sequence for moving off 1C Enterprise 7: what to analyse, what to migrate, how to validate the result and where projects usually go wrong.
Companies still running 1C Enterprise 7 usually have two things in common: the system has been in place for a long time, and it has been extended by several people over the years. Both facts shape how a migration should be planned.
Start with what is actually in use
The first deliverable is not a plan — it is an inventory. Before anything is designed, you need to know:
- which document types are created every month, and by whom;
- which reports are used for decisions, and which are printed out of habit;
- which customisations still run, and which are dead code;
- which exchanges with other systems exist, including manual ones.
On a long-lived 1C 7 installation, the gap between “what exists” and “what is used” is often large. Migrating the second set instead of the first is what keeps a project finite.
Decide the data scope early
Data scope drives most of the effort, so it should be an explicit decision rather than an assumption:
- Master data — partners, products, price lists, warehouses. Always migrated, usually cleaned first.
- Opening balances — stock quantities, receivables, payables. Migrated and reconciled to the last unit.
- Document history — the real question. Two full years is a common choice; ten years of documents is usually a reporting requirement that can be met by keeping the old system readable in archive mode instead.
Agree the depth in writing. Changing it halfway through re-opens the mapping work.
Map structures, not just tables
A field-by-field mapping is not enough. What matters is meaning:
- how analytical dimensions were used for reporting;
- what document statuses actually mean operationally;
- which custom fields carry business rules that were never documented;
- how numbering is expected to continue after go-live.
This is the stage where a legacy migration turns into a modernization: some structures should be carried over, and some exist only because of limitations that no longer apply.
Migrate repeatedly, into a test environment
A migration that runs once, at go-live, is a gamble. The working pattern is:
- Load into a test environment.
- Reconcile: totals, balances, document counts, stock per warehouse.
- Fix the mapping — not the data by hand.
- Repeat until the run is stable and reproducible.
By the third or fourth run, the migration script should produce the same verified result every time. That is what makes the final load at cut-over a routine step.
Validate with the people who use the system
Reconciliation proves the numbers are right. User acceptance testing proves the business can operate. Both are needed. Give key users real scenarios — a full sales cycle, a receipt, a stock transfer, a month-end report — and track issues until they are closed.
Where 1C 7 projects usually go wrong
- Migrating everything. Effort explodes and validation becomes impossible.
- Copying the old process exactly. Workarounds get reproduced as requirements.
- Skipping data cleaning. Duplicate partners and products multiply after migration.
- No written cut-over plan. Go-live becomes improvisation.
- Believing a fixed timeline before the analysis. Duration follows scope, not the other way round.
What an honest proposal looks like
Nobody can promise a fully automatic migration, zero downtime or a fixed cost before analysing your specific database. What can be committed to is a method: analysis, mapping, repeated migration runs, reconciliation, testing and a rollback option at cut-over.
If you are planning this move, our migration methodology sets out each phase and what it produces.