Migrating from 1C/BAS: How to Protect Website, CRM, and Marketplace Integrations
- Legal context: what to check before planning
- Where migration risk arises
- Inventory: document each data flow separately
- Common data flows and what to check
- When an integration layer can help
- Seven steps for migrating integrations
- Rollback and recovery: agree on the plan before launch
- How to assess a new system’s integrations
- Frequently asked questions
- Sources
Replacing 1C/BAS can look like an accounting task—until the website shows yesterday’s stock, a marketplace accepts an order for an item that has sold out, or a sales manager cannot see a new customer in the CRM. An accounting system usually exchanges data with several channels, each with its own rules, format, and owner. To move to another platform without a scramble of manual fixes, first map those data flows, then migrate them in separate, verifiable steps.
Legal context: what to check before planning
Cabinet of Ministers Resolution No. 1335 approved the procedure for compiling and maintaining a list of software and equipment that pose risks. It does not state a universal ban for every private company. The State Service of Special Communications publishes specific entries, while requirements depend on the system, data, the organization’s or operator’s status, and other circumstances. Before making a decision, check the specific product against the current list and obtain legal advice for your situation.
Draft Bill No. 13505 was rejected and withdrawn from consideration on 30 June 2026. The 2% of turnover figure and 2030 date discussed in connection with it are not enacted law under that bill. Keep this separate from the technical plan: an integration inventory helps make a migration manageable, but it does not by itself determine whether a company has a legal obligation to migrate.
Where migration risk arises
An integration is more than a connection between two systems. It includes the data source, transformation rules, timing, error handling, and a way to verify the result. A product, for example, may have different codes in the accounting system and on the website; an order may have several statuses; inventory may include reservations across multiple warehouses.
Replacing a system changes more than an API or file format. Identifiers, status meanings, units of measure, directory structures, time zones, and update rules may differ. If you reproduce only the technical connection and miss the business rules, data can reach its destination and still be wrong.
Inventory: document each data flow separately
Build a register of exchange directions, not just a list of systems. One service may have several independent flows: it may receive a product catalog and send orders, for example. For each flow, record:
- Data and purpose: exactly what is transferred and which process uses it.
- Source and recipient: which system owns the data and which only uses a copy.
- Direction and mode: one-way or two-way exchange, scheduled, event-driven, or manual.
- Identifiers and rules: matching keys, directories, transformations, currencies, and units of measure.
- Technical contract: API, file, direct database access, or intermediary service; format, authentication, and limits.
- Recovery and control: where errors appear, how to retry an operation, how to reconcile the result, and who responds.
- Owner: the business owner and technical team, including a contractor if they maintain the connection.
Do not overlook spreadsheets handled manually, email imports, overnight batch uploads, or local scripts. They are often missing from documentation but remain part of day-to-day work.
Common data flows and what to check
| Flow | Typical direction | Migration checks |
|---|---|---|
| Products, prices, inventory | Accounting → website, marketplaces, bot | SKU, warehouse, reservation, currency, and update-time mapping |
| Orders | Sales channels → accounting | Unique key, retries, statuses, and duplicate prevention |
| Customers and counterparties | Accounting ↔ CRM or B2B portal | Record-merging rules, access, and conflicting changes |
| Payments and delivery | Payment/logistics services ↔ accounting | Status mapping, amounts, timestamps, and repeated webhooks |
| Rewards, discounts, limits | Accounting ↔ CRM or loyalty program | Balance ownership, accrual rules, and duplicate-redemption controls |
| Documents and reporting | Accounting → e-document exchange, email, BI | Period completeness, format, archive, permissions, and totals reconciliation |
This is a starting list, not a universal checklist. Add warehouse, production, service, or wholesale flows if they are part of your processes.
Integration examples are not migration case studies. The MedHouse Club case describes an exchange of catalog, prices, availability, and orders between an accounting system and Telegram/Viber stores. It shows how an accounting system can support several channels. It does not establish that the project involved a migration from 1C/BAS to another platform.
NFM AGRO illustrates a different scenario: a mobile CRM exchanges data with an ERP through a REST API. This is an ERP–CRM integration example, not evidence of a 1C/BAS migration. Examples can help illustrate flow types, but you still need to establish the scope and behavior of your own integrations.
For broader context, see these published articles on business process automation and n8n in business workflows. Automation tools can support individual flows, but they do not, by themselves, replace an accounting or ERP system.
When an integration layer can help
If many channels depend directly on the accounting system, a separate integration layer can shield them from its internal format. Adapters transform data into an agreed model, while channels work against a clearly defined contract. If the core system changes later, you can update the adapters and rules instead of rebuilding every connection separately.
This is an architectural option, not a prerequisite for migration. Separate connectors may be enough for a small number of simple flows. The right choice depends on the number of systems, how often they change, observability needs, and the support team’s capacity. Replace direct queries to an internal database only after assessing the risks and agreeing on the approach with the system vendor.
Seven steps for migrating integrations
- Document the current state. Save diagrams, settings, schedules, sample messages, connector versions, and contact details. Check: another person can explain the purpose of every flow.
- Define the target data model. Agree on directory owners, identifiers, statuses, required fields, and transformation rules. Check: every field has a source, a meaning, and a mapping rule.
- Prepare an adapter and test environment. Move the exchange to a test installation without sending test orders into live processes. Check: access is limited and logs contain useful errors without secrets.
- Test scenarios and edge cases. Cover successful creation, updates, cancellation, duplicates, partial failures, empty values, and one system becoming unavailable. Check: critical business rules match the agreed examples.
- Run a controlled parallel test. If the architecture allows, compare the new system’s results with the old system using copies or a mode that makes no side-effecting writes. Check: discrepancies are categorized and explained before cutover.
- Switch flows one at a time. Agree on the window, owners, success criteria, and rollback route. Check: test orders, inventory, and statuses reach the destination; a repeated message does not create a duplicate.
- Reconcile data and retire the old route. Compare document counts and totals, inventory, statuses, and pending operations for an agreed period. Check: the business owner has accepted any discrepancies, and the old route is disabled only after agreement.
A message queue can help handle temporary failures, but it does not by itself guarantee that nothing will be lost or duplicated. You also need idempotent operations, controlled retry policies, reconciliation between source and recipient, and a separate dead-letter store for messages that could not be processed. Assign an owner and reprocessing procedure to every such record.
Rollback and recovery: agree on the plan before launch
Before cutover, decide who can stop the new flow and what signals should trigger that decision. Keep access to the previous configuration, record a recovery point, and describe how to handle records that have already entered the new system. Restoring the old connector without coordination can create two competing versions of the truth, so check separately whether data has been written to both systems.
Set a response deadline, escalation channel, and manual-handling process for critical orders. If rollback would otherwise lose new records, the plan should include an export or another agreed way to move them back. Rehearse the scenario in a test environment before relying on it during an incident.
Risks that are easy to miss:
- Unknown dependencies: an old script or manual export was left out of the register.
- Semantic differences: similar status names represent different stages of a process.
- Redelivery: a webhook or request arrives again and creates a duplicate without an idempotency key.
- Silent loss: a message fails and the system does not show it in an error queue.
- Time discrepancies: different time zones or delays change the order of updates.
- Excessive access: temporary keys remain active after testing or cutover.
- Premature shutdown: the old connection is stopped before reconciliation and pending-data processing are complete.
Logs and regular reconciliation may be enough for minor auxiliary flows. Critical orders, payments, and inventory need explicit error alerts, controlled retries, and a named owner who responds to discrepancies.
How to assess a new system’s integrations
Compare systems using your own flows and test cases. Ask about a documented API or supported import formats, stable identifiers, webhooks, rate limits, logging, backups, a test environment, and the update process. Find out who owns the data and whether you can export it in a usable format.
Ask vendors to demonstrate more than a successful exchange: see how the system handles invalid data, duplicates, timeouts, and another system becoming unavailable. Assess the full support cost: connectors, monitoring, API changes, manual exception handling, and internal team time. Do not choose a system based on a claim that it “connects to everything” without checking your actual scenarios.
BotLabs designs CRM/ERP systems and their integrations; see our CRM development service for the relevant scope.
Plan a controlled transition. A reliable move starts with a map of data flows and rules, not with the first connector. Agree on the data model, test failures and duplicates, roll out new flows gradually, and reconcile the results with the business. A parallel run can reduce uncertainty, but its value depends on good test data, idempotency, and a recovery process.
Frequently asked questions
No. Resolution No. 1335 established a procedure for maintaining a list; it did not impose a universal ban on all private companies. Check the specific product, system, data, and requirements that apply to your company with a lawyer.
Draft Bill No. 13505, which was associated with these proposals, was rejected and withdrawn from consideration on 30 June 2026. The proposed 2% figure and 2030 date did not become law through that bill.
No. A queue helps manage retries, but you also need idempotency, reconciliation between systems, monitoring, and a dead-letter mechanism for failed messages.
Not always. It can help when many channels depend on the accounting system or exchange rules change often. Separate connectors with suitable logging and support may be enough for a few simple flows.
When agreed scenarios have passed, critical discrepancies have been explained, sample records have been reconciled, and owners know the stop and recovery procedures. Switch flows separately and check them after launch.
Sources
- Verkhovna Rada of Ukraine: Draft Bill No. 13505 record.
- Verkhovna Rada of Ukraine: Cabinet of Ministers Resolution No. 1335 record.
- Government Portal: the software list and its intended audience.
- Government Portal: June 2026 update to the list.
- State Service of Special Communications: answers on the scope of the list.
- BotLabs: NFM AGRO — CRM with ERP data exchange.
Talk to a specialist about moving from 1C/BAS
In 15 minutes, we’ll review your process and identify the first step toward implementation.
Implementation starts
with a clear plan.
Let’s discuss your accounting, website
and CRM — and the first step.
