Moving from 1C to IFS Cloud: what to know upfront

Many companies in Central Asia started on 1C, and for good reason: accountants know it, specialists are easy to find, and it handles local accounting well. But as the business grows, new needs appear that 1C was never designed for. That is when the question of moving to IFS Cloud comes up. Here is what to think through before the project starts.

Why companies outgrow 1C

• Several legal entities and countries, with consolidation assembled by hand in Excel.
• Many separate configurations linked by data exchanges that break regularly.
• Heavy customisation, so every update becomes a project of its own.
• A need for enterprise-grade asset, project, service or manufacturing management.
• Shareholders, banks or a foreign parent company asking for management reporting to international standards.

If two or three of these sound familiar, the move is at least worth costing out.

What to migrate and what to leave behind

The main rule: don’t migrate history for the sake of history. Three groups of data usually move to the new system.

• Master data: customers and suppliers, items, fixed assets, chart of accounts, employees, warehouses. This is the foundation, and it must be cleaned before migration.
• Opening balances at the cut-over date: accounts, stock, receivables and payables, fixed assets with accumulated depreciation.
• Open documents: unfulfilled purchase and sales orders, unpaid invoices, active contracts, work in progress.

Detailed transaction history from prior years is usually kept in 1C in read-only mode or exported to a data warehouse for analysis. That is cheaper and safer than moving millions of postings.

Clean data before, not after

Duplicate counterparties, items with inconsistent units of measure, fixed assets without tag numbers — 1C has tolerated all of this for years. IFS Cloud is stricter about data quality, which is a good thing. It also means cleansing has to start several months before go-live, with a named owner for every master data set.

Run at least two or three trial migrations into a test environment. Each one ends with a reconciliation: balances in the new system must match 1C with no differences.

Running in parallel

Keeping books in two systems sounds safe but is expensive: people have to enter everything twice. It is usually better to pick a short window, such as one reporting month, during which the old system stays available for reconciliation while day-to-day work already happens in IFS Cloud. Agree the criteria in advance: which reports are reconciled, who signs off, and which differences would trigger a rollback.

Choose a cut-over date at the start of a period — a month, or better a quarter or a year. That makes it easier to close the old period and open the new one.

Local accounting and tax reporting

IFS Cloud is an international system, and each country’s legal requirements are handled through localisation and configuration. Work out early how statutory accounting and tax reports, electronic invoices, and exchanges with government services and banks will be produced.

There are different options: run local accounting in IFS Cloud with configured reports, or keep a separate statutory ledger connected by an integration. The right answer depends on the country, the industry and the requirements of your chief accountant and auditors. What matters is to decide during design, not a month before go-live.

Integrations and the surrounding landscape

List everything currently connected to 1C: online banking, cash registers, the online store, warehouse scanners, payroll, BI reports. For each connection, decide whether it moves to IFS Cloud, gets replaced or stays as it is. HR and payroll are a separate question: they are often kept in a specialised local system, with only summary postings sent to IFS Cloud. Decisions like these have a real effect on project scope, so they are best made during diagnosis.

Moving off 1C is above all a data and people project, not a programming one.

Training and changing habits

1C users are used to a particular logic: document, posting, registers. IFS Cloud has different concepts and a different sequence of steps. Build training around roles and real scenarios: how an accountant closes the month, how a storekeeper receives goods, how a buyer raises an order.

• Name key users in every department and involve them from the design stage.
• Train in a test environment loaded with your migrated data, not a demo database.
• Write short role-based guides instead of one thick manual.
• Plan for extra support during the first weeks after go-live.

Where to start

Start with a diagnosis: which 1C processes and customisations the business actually needs, and which have simply accumulated over time. That shapes the project scope, the migration plan and the approach to local accounting. The more honest that picture, the smoother the move.