Moving from 1C 7.7: what to check before the migration

Many companies still keep their accounting in programs written on 1C:Enterprise 7.7. The programs work and the accountants know them, and that is the main reason the move is postponed year after year. Meanwhile the risks grow: fewer specialists know the old platform, new requirements are harder to meet, and exchanges with banks and government services are built for current products.

A migration is not a copy of the old database into a new program. These are the questions to settle before it starts.

What exactly is being replaced?

Over the years a 7.7 database collects changes: documents added by a programmer who left long ago, reports that somebody still uses, exchange files for other programs. Make the list before the estimate. For every changed object decide whether it is still needed, whether the new product already has it as standard, or whether it has to be built again.

Much of the list usually falls into the second group. Functions that had to be written by hand on the old platform are standard in current products.

How much history is needed?

There are two ways to move. The first is to transfer opening balances on a date and work in the new system from that date. The second is to transfer the documents of previous periods as well.

Balances are faster and cleaner. History is needed where the new system must rebuild something from documents: settlements under contracts, depreciation, cost calculation, average earnings in payroll. Decide it area by area. The old database stays available for reading in any case.

Is the data fit to move?

Old databases carry duplicates, items marked for deletion, counterparties without tax numbers and balances nobody can explain. Moving them means starting the new system with old errors.

Before the transfer, close what can be closed: reconcile settlements with customers and suppliers, count the stock, write off what does not exist. Each cleaned balance is one question less after go-live.

How is the transfer checked?

The transfer is accepted on evidence, not on trust. Compare both sides in two ways: totals by account, and individual records. Totals may match while individual customers or items carry wrong amounts that offset each other.

A reconciliation report that lists every difference with its explanation should be part of the acceptance documents.

When is the switch?

The start of a year or of a quarter is the convenient date for accounting. Payroll may need the start of the year for its own reasons. Plan a period when the main operations are entered in both systems, short enough not to exhaust the accountants and long enough to close one period and compare the results.

Who has to learn what?

The new interface looks different, and the logic of the documents has changed. Accountants who knew every key of the old program become beginners for a few weeks. Training by role, on the company's own data, before the switch shortens that time more than anything else.

The usual result

A prepared migration is uneventful. The first month is closed in the new system, the figures match the old one, and after the second closing nobody opens the old program except to look something up.