SAP → 1C: five risks that need to be assessed before migration
The SAP → 1C migration fails not because of the platform itself, but because of the attempt to migrate the system as a set of screens without understanding the business logic.
Five decisions before the start
What we save
Which SAP business logic is really needed and which should be rethought in the target Russian ERP environment.
What data do we transfer?
History, balances, contracts, master data, documents, analytics, archive and reconciliation rules.
How to close reports
Financial, management, regulatory and operational reporting should be designed before migration.
How we change processes
Users need to understand the new experience, not just the new interface.
What do we use to divide into stages
By what boundaries is the transition divided—environment, legal entity, accounting unit—and what constitutes successful completion of each stage.
Five risks: indicator, consequence, measure
A risk map is useful when, for each item, it’s clear how it’s detected before launch, what consequences it has on the project, and what actions are taken to address it. Below are five risks that most often determine the outcome of a migration.
| Risk | How to recognize in advance | What it leads to | What to do |
|---|---|---|---|
| Underestimation of integrations | There is no complete list of exchanges: banks, EDI, DWH and BI, portals, warehouse and production; some exchanges rely on scripts with no owner. | Exchanges surface during the testing phase, deadlines slip, and some operations are handled manually for a period of time. | Inventory of integrations with owner and traffic volume for each; the integration environment is designed in parallel with the functional one, not after it |
| Loss of informal logic | Key calculations reside in modifications that no one has documented; only one person can answer the question “why is it calculated this way.” | After the transition, the amounts diverge, and there's nothing to restore the original rule from. | Reviewing enhancements with business owners prior to design, documenting rules in requirements, acceptance tests based on historical examples |
| Dirty reference data | Duplicate counterparties and nomenclature, unfilled mandatory attributes, inconsistent classifiers across different modules | Data migration multiplies errors, reporting doesn't balance, and users don't trust the new system | Cleaning and deduplication before migration, master data management rules and responsible persons, automatic quality checks on upload |
| Late-stage design of reporting and control procedures | Reporting is discussed after the core functions are launched; the list of mandatory forms and controls has not been compiled. | The first period closing is done manually, regulatory forms are compiled in tables, increasing the risk of errors in reporting | List of mandatory reports and controls—at project inception; test period closing prior to transition to production |
| Lack of a phased transition plan | The plan looks like a "big bang migration"; there is no pilot area, acceptance criteria, or rollback scenario. | Any issue at the start halts the entire operational work, with no fallback option. | Phased rollout by contours or legal entities, pilot on a limited scope, acceptance criteria and rollback plan for each phase |
Where to start
Analyzing these five risks within a specific landscape is the subject of a brief assessment, not a multi-month pre-project phase. Next comes the migration program: target architecture, data migration, reconciliation, cutover, and support.
Let's discuss your environment
Describe the task, current systems, constraints, and expected results. We will offer a practical first step: diagnostics, pilot, audit, roadmap or project team.
