How to Migrate from 1C 8
Migrating from 1C Enterprise 8 is less about data extraction and more about untangling years of customisation. Here is how to approach it.
Compared with version 7, a 1C 8 installation is usually richer in data and heavier in customisation. That changes where the difficulty sits: extracting the data is rarely the problem, deciding what deserves to be carried forward is.
The customisation question comes first
Most long-running 1C 8 systems accumulate three layers:
- The standard configuration.
- Adjustments made during implementation.
- Years of small changes requested by users and departments.
The third layer is where the work is. It contains genuine business logic, but also fixes for problems that no longer exist, features built for a customer who left, and reports nobody opens.
Start with usage analysis: which objects are written to, which reports are executed, which processing routines run on a schedule. A month of usage data answers questions that months of workshops otherwise would.
Separate business rules from implementation details
Once you know what is in use, each customisation falls into one of three groups:
- Business rules to preserve — pricing logic, approval thresholds, warehouse procedures. These are requirements, and they must be reproduced in the new platform, though not necessarily in the same shape.
- Workarounds to retire — steps that exist because the old system could not do something directly. Reproducing them carries the constraint forward.
- Dead weight to drop — unused objects and code. Document the decision, then leave them behind.
Data volume needs a real decision
1C 8 databases are often large. Migrating everything is technically possible and almost always the wrong choice: it slows every migration run, complicates reconciliation and makes user testing harder.
A practical structure:
- full master data, cleaned and de-duplicated;
- opening balances reconciled to the unit;
- an agreed depth of document history for operations and reporting;
- the legacy system kept available read-only for older history.
Integrations deserve their own workstream
1C 8 installations usually sit in the middle of a web of exchanges: bank statements, marketplaces, courier services, accounting, fiscal reporting. Each one needs:
- an owner;
- a target design (API where possible, structured file where not);
- identifier mapping between systems;
- error handling and monitoring;
- a test with the real counterparty before go-live.
Integrations that are discovered late are the single most common cause of a delayed cut-over.
Plan the cut-over as an operation
For a business with daily transaction volume, the cut-over is an operational event, not an IT task. It needs a written sequence: freeze point in the legacy system, final data load, reconciliation checkpoint, sign-off, opening of the new system, and a defined rollback condition.
The rollback option matters even if it is never used. It is what allows the decision to go live to be made calmly.
What not to promise
Even with a clean 1C 8 database, no honest supplier can commit to a fully automatic migration, zero downtime or a fixed price before the analysis. What can be committed to is the method, the checkpoints and the fact that data is validated by reconciliation before anyone goes live.
If you are evaluating the move, the RATON migration methodology describes the eleven phases and what each one delivers.