A company works in 1C for years, accumulating directories, documents, and history. Eventually it notices that reports are still assembled by hand, part of the operation lives in spreadsheets, management answers arrive too slowly, and every change requires another customization. A natural question follows: can the business gradually move to its own, more automated and convenient system?
It can. But a safe transition is not a one-day software replacement. It is a controlled transfer of data, rules, and operations, with explicit checks at every stage. The business keeps running, and the old system is retired not on a date chosen in advance, but only after the new one has proved that it performs the same work correctly.
The main mistake: building directly on 1C tables
Once a company gains access to the database, the shortest route looks obvious: connect a new interface directly to 1C tables and keep adding features around them. This is genuinely fast at first. It also makes the new system inherit the internal structure of the old one and remain permanently dependent on it.
1C tables are the technical implementation of a particular configuration, not a clean description of your business. Names, relations, and storage details can change after an update. Some rules live not in the data itself but in document posting, processing routines, and configuration code. If those tables become the foundation of the new product, leaving 1C later will require another complete rewrite.
The core rule is therefore simple: the new system must own its data model, while 1C connects through an adapter as a temporary source.
The general structure looks like this:
1C → adapter → custom data model → new system modules
Today the adapter reads facts from 1C. Tomorrow its place may be taken by another accounting package, an API, equipment, or the new system itself. The modules above it do not need to change because they work with stable business concepts rather than internal source tables.
What a canonical model means in practice
The term sounds technical, but the idea is practical. A canonical model is the single language the new system uses to describe the company: product, customer, order, warehouse, batch, delivery, production plan, payment. It stores what these entities mean to the business, regardless of how they are named or distributed inside 1C.
One configuration may keep shipment weight in sales lines; another may derive it from product attributes and delivery documents. In the custom model it is always one clear field: “shipped, kg.” The adapter knows how to obtain it from a particular source. Reports, charts, and algorithms above that boundary no longer depend on the source’s technical details.
This does not mean one universal database for every company. The common core repeats: products, people, legal entities, documents, movements, permissions, and audit. Industry rules are added separately: bills of materials for manufacturing, serial numbers for equipment, or batches and expiry dates for food products.
A general migration plan from 1C
1. Audit how work actually happens
Start with real operations, not the database structure. Which documents are created? Who approves them? Where do stock figures come from? Which reports are assembled manually? What lives outside 1C? Which informal rules are known by only one employee?
The result should be a map of processes and data: what will be migrated, what will remain, what is no longer used, and which numbers are treated as reference totals. Without this step, it is easy to automate a collection of old forms instead of the actual business.
2. Design an independent model
Business entities and rules are then described independently of 1C. Stable identifiers, relations, units, document states, permissions, and an audit trail are defined here.
Do not copy every source field “just in case.” A field belongs in the canonical model when it has a clear meaning and owner. Source-specific details stay inside the adapter.
3. Connect 1C in read-only mode
The first production connection should be one-way: the new system receives facts regularly but writes nothing back. Depending on the configuration, this may use a supported interface, file exchange, or a dedicated data adapter.
Read-only operation makes it possible to build analytics, validate the model, and find errors without risking the live books. At this stage, 1C remains the only place where operations are created.
4. Migrate history and establish control totals
Current balances alone are not enough. History is needed for seasonality, forecasting, comparisons, and proof that the new calculations are correct.
After loading, the data is reconciled through control totals: document counts, weight, inventory, turnover, production, and receivables, split by period and business unit. A discrepancy is not rounded away. Its cause is found and the resulting rule is recorded.
5. Run a parallel operating layer
The new system now works beside the old one. It produces reports, plans, alerts, and management decisions from the same facts but does not yet control primary transactions.
This stage tests more than monthly totals. It checks daily behavior: whether the correct customer is selected, whether a shared delivery is counted twice, and whether inventory still reconciles after each movement. A parallel period is much safer than a big-bang launch on Monday morning.
6. Transfer operations one module at a time
Once a domain reconciles reliably, the new system can be allowed to create its operations. The usual starting points combine high management value with lower regulatory risk: planning, logistics, internal requests, approvals, and employee workspaces.
For a while, the custom system may create a document and the adapter may send it to 1C for accounting. Employees already work in the better interface while the accounting layer continues to receive familiar records.
7. Assign one authoritative writer to every domain
This is the second fundamental rule: at any moment, only one system may create and change a given type of operation.
While warehouse operations are owned by 1C, the new system only reads them. After cutover, warehouse documents are created in the new system and 1C, if still required, receives a copy. Allowing both systems to edit the same inventory guarantees two versions of the truth.
8. Move statutory accounting last
Accounting entries, taxes, period close, and statutory reporting contain the most rules and carry the highest cost of error. 1C may therefore remain an accounting recipient long after sales, inventory, logistics, manufacturing, and planning have moved to the custom system.
That is not an incomplete migration. It is sensible risk ordering. The regulated layer is retired last, after separate reconciliation, audit, and approval by the people responsible for it.
How to know when an old module is ready to retire
The decision is based on evidence, not on “two months have passed.” A module is ready when:
- historical data is migrated and available for inspection;
- control totals reconcile consistently;
- new transactions complete the full path from creation to reporting;
- permissions and the audit trail have been tested;
- the team works in the new interface without parallel spreadsheets;
- backups, recovery, and a rollback procedure are in place;
- there is an exact boundary after which the old source becomes read-only history.
Only then is the 1C module switched to read-only mode and later removed from daily work.
Does this approach work for every company?
The principle works broadly. Manufacturing, retail, logistics, and service businesses can all separate their own model from the source, prove correctness in parallel, and transfer responsibility in stages.
What changes is the scale, module order, and industry logic. One company may struggle with batch tracking, another with manufacturing cost, and another with contracts and payments. Much of the technical migration can be repeated, but business meaning still has to be discovered with the people who perform the work.
The result is not “another interface on top of 1C,” but a digital foundation owned by the company. At first 1C supplies facts. Later it becomes only an accounting recipient. Eventually it can be replaced completely, without stopping operations and without another large rewrite at the end.
If you are considering this path, begin with a process audit and a map of all data sources. Only then can you decide honestly which parts should be extended in the current system and which processes deserve their own foundation.