Data Migration to 1C with Reconciliation
We migrate products, SKUs, barcodes, prices, counterparties and balances from an old database, Excel or another accounting program into 1C 8.3. First we reconcile and clean, then we load: to a copy, and only after accounting signs off, into the live database.
- Reconciliation of two databases by products, barcodes, prices and counterparties
- Duplicates and mismatches found before loading, not after
- Balances go to a copy first, into the live database only after reconciliation
- Correction files and a log: what was moved, what was not, and why
Data migration to 1C starts at 600,000 tenge. Catalogs and balances are migrated in three to five weeks, and migration with document history takes from six weeks.
When you need data migration to 1C
A switchover, a merger or a cleanup.
Data migration to 1C is needed in a few typical situations. A company moves to 1C 8.3 from an old configuration or from version 7.7. Two databases, for example trade and accounting, or two legal entities, are merged into one. Records were kept in Excel for years and now need to go into a proper system. Finally, a database is so overgrown with duplicates and junk that it is easier to move clean data into a new one than to clean the old one.
In every case the task looks simple: export and import. In practice the loading itself takes a couple of days, and most of the time goes into making the data match. The same item has different names in two databases, an SKU has an extra space, one barcode is attached to two products, a counterparty exists three times with different BINs. Moved as is, all these problems travel into the new database along with the data.
That is why we do not sell loading; we sell migration with reconciliation: a result that accounting signs off on, not a file that "seems to have loaded".
The source does not have to be 1C. We have migrated data from in-house software, warehouse systems, online store exports and Google Sheets. If the source can export to a file or provides database access, the data can be retrieved.
What we migrate
Catalogs, prices, balances and, if needed, history.
| Data | What we check | Typical problem |
|---|---|---|
| Products | Names, SKUs, units of measure, groups | One item entered several times under different names |
| Barcodes | Uniqueness, link to product variants | One barcode on two products, the till rings up the wrong one |
| Prices | Price types, currency, effective date | The old database has prices from the old list, Excel from the new one |
| Counterparties | BIN and IIN, contracts, bank accounts | Duplicates with the same BIN, empty details |
| Balances | Stock by warehouse, cash, settlements | Negative stock, reservations never released |
Document history is migrated less often and costs more: it has to be not just loaded but posted in the new configuration, where posting rules differ. Usually balances as of the switchover date plus access to the old database for reference are enough.
Additional data is agreed separately: product attributes, batches, photos for the website, contracts with counterparties, contact persons, bank accounts. Each such field adds reconciliation work, so the plan includes only what you actually use. Fields nobody has filled in for five years are not worth migrating.
How the migration works: eight steps
An order of work that protects the live database.
- Export. We export catalogs and documents from the old database, Excel or other software into working tables.
- Reconciling two databases. We match products, SKUs, barcodes, prices and counterparties between the source and the target.
- Finding duplicates and mismatches. We find identical items under different names, repeated barcodes, counterparties with the same BIN.
- Correction files. We prepare tables: what to merge, what to rename, what to delete. You make the decisions on disputed items.
- Loading catalogs. We load products, barcodes, prices and counterparties into a copy of the database.
- Balances on the copy. We enter stock, cash and settlement balances as of the switchover date.
- Reconciliation with accounting. The accountant checks turnovers and closing balances, and we fix discrepancies until everything matches.
- Move to the live database. Only after accounting signs off do we repeat the load into the live database using the proven procedure.
Reconciling two databases: where errors hide
The main work happens before loading.
Reconciling two databases starts with choosing a matching key. The name does not work: "VVGng cable 3x2.5" and "VVG-ng cable 3*2.5" are different products to a program. The SKU is better, but it can be empty or duplicated too. The barcode is the most reliable, but not every item has one. Usually we build a composite key and test it on a sample before applying it to the whole catalog.
Then we compare values field by field and build a discrepancy report: which product has a different price, unit of measure or group in the two databases. For counterparties we reconcile BIN and IIN, contracts and bank accounts. We pay separate attention to items that exist in only one database: they are either new products or junk nobody has deleted for years.
Merging the databases of two legal entities adds another layer: intercompany settlements and goods one company sold to the other. These have to be netted correctly rather than just moved, otherwise the new database will show the company owing money to itself.
What you get is a clear table, not a hundred thousand rows: how many records matched automatically, how many need a human decision, and which options we propose for each group.
Duplicate products and counterparties
Easier to remove during migration than to live with afterwards.
Duplicate products appear when several people create items without shared rules: one writes "Screw 4.2x19", another "Screw 4.2*19 mm". Stock is spread across cards, reports lie, and two items go to the website and Kaspi instead of one. Counterparties are the same: one buyer under three cards with different balances owed.
We look for duplicates in several ways: by normalized name (without spaces, case and units of measure), by SKU, by barcode, by BIN. Every group found is shown in a file with a suggestion of which card to keep as the main one. We merge only after your confirmation: sometimes two similar products really are different.
If duplicates need to be removed from a working database without migration, that is our job too: we write a merge data processor that moves balances and document references to the main card. More in our article on how to find and merge duplicate products (in Russian).
Importing products and prices from Excel into 1C
The most common data source and the most temperamental.
Importing from Excel into 1C looks simple: standard configurations include a standard import from a spreadsheet. It works well on a tidy file and badly on a real one: merged cells, prices stored as text, SKUs that Excel turned into dates, units of measure written two different ways.
For a one-time import we clean the file and load it with standard tools. For a recurring one, such as a weekly supplier price list, we write an external data processor for your format: it matches items by SKU or barcode, updates prices, sets new products aside for review and shows a change log.
A step-by-step guide with typical mistakes is in how to import products from Excel into 1C (in Russian).
Migrating balances: copy, reconciliation, live database
Why we never load balances straight into the live database.
Balances touch everything: warehouse, cash, settlements with customers and suppliers. An error in balances does not surface immediately but a month later, when the ledger does not tie out or the warehouse sells what is not there. Fixing it in a live database where documents are already being posted is slow and risky.
So the order is strict. First the balances go into a copy of the database. Accounting reconciles turnovers and account balances, the warehouse spot-checks quantities, managers review the balances owed by key clients. We fix discrepancies and repeat until everything matches. Only after the reconciliation is signed do we repeat the load into the live database: with the same script, on the same date, so the result is predictable.
Details and a reconciliation checklist are in migrating balances to a new 1C database (in Russian).
Moving to 1C 8.3 and database compression
Two special cases of data migration.
Moving to 1C 8.3 from an old configuration or from 7.7 is technically handled with Data Conversion or the EnterpriseData universal format, if ready-made rules exist for the pair of configurations. If there are no rules or the old database is heavily customized, we write our own migration rules. Either way the order is the same: copy, reconciliation, live database.
Database compression (rolling up history) is needed when a database has grown over the years to a size that slows down work and updates. It removes old documents and replaces them with opening balances as of a date. Before compression we always make a full copy and reconcile balances before and after: the same reconciliation as in a migration.
If you also need a new server for the grown database, see servers for 1C (in Russian). More on the switchover in moving to 1C 8.3 without data loss (in Russian).
Timelines, cost and what you get
We estimate after reviewing both databases.
| Scope | Timeline | Price |
|---|---|---|
| Catalogs and balances, one source | 3-5 weeks | from 600,000 ₸ |
| Merging two databases with reconciliation | from 5 weeks | by estimate |
| Migration with document history | from 6 weeks | by estimate |
| Data processor for recurring Excel imports | from 1 week | from 150,000 ₸ |
At the end you get migrated and reconciled data, a migration log (how many records, what was merged, what was set aside and why), correction files with your decisions and a balance reconciliation act signed by accounting. The data processors we wrote for the migration stay with you and come in handy for repeat imports.
Payment is by stage: audit and plan, reconciliation and correction files, loading to the copy, move to the live database. Each stage is closed with an act, so you pay for a finished result, not upfront for the whole project. If the audit shows the migration can be done more cheaply with standard tools, we say so.
Timelines most often depend not on us but on how quickly decisions are made on disputed items. So at the start of the project we agree who on your side is responsible for products and who for counterparties and balances.
How we differ from a franchise partner and a freelancer
A migration that is accountable for its result.
A freelancer usually offers to "load it in a couple of days", and does load it: duplicates and errors included. A franchise partner migrates standard databases well using ready-made rules, but is reluctant to take on complex cases with a customized old database and reconciliation of several sources.
Both approaches share one flaw: the migration is handed over when the data is loaded, not when it is reconciled. Problems surface later, after the contractor has closed the job.
We treat migration as a project: plan, reconciliation, log, accounting sign-off. We also build 1C integrations with websites and Kaspi ourselves, so we make sure from the start that after migration products export to marketplaces without duplicates and with correct barcodes. If customizations are needed after the migration, a 1C developer from the same team handles them.
FAQ about data migration to 1C
Timelines, reconciliation and risks.
How much does data migration to 1C cost?
From 600,000 ₸ for catalogs and balances from one source, 3-5 weeks. Merging several databases and migrating document history are estimated after a review: the scope depends on the quality of the source data.
Can data be migrated from Excel?
Yes. First we tidy up the file: units of measure, SKUs, prices as numbers. Then we load it into a copy, check it and only then move it to the live database.
Will work in the old database stop?
No. While reconciliation is under way, you keep working in the old database. On switchover day we fix the balances as of the date and load them into the new database using the proven procedure, usually in one or two days. It is convenient to plan the switchover for the start of a month or quarter to make reporting reconciliation easier.
What do you do with duplicate products?
We find them by name, SKU, barcode and BIN and show them in a file with a suggested main card. We merge only after your confirmation: sometimes two similar products really are different, for example in color or pack size.
Do you migrate document history?
We can, but we do not always recommend it: history has to be reposted under the rules of the new configuration and costs noticeably more. Balances plus access to the old database are often enough.
How do you migrate from 1C 7.7?
With ready-made conversion rules if they fit, or with our own rules for a customized database. The order is the same: copy, reconciliation with accounting, live database.
Who checks the result?
Your accountant reconciles turnovers and balances on the copy of the database. We fix discrepancies until the reconciliation ties out, and only after sign-off move the data to the live database. The reconciliation act stays with you and is useful during audits.
Can the supplier price list import be made recurring?
Yes, we write an external data processor for the supplier's format: matching by SKU or barcode, price updates, a change log. From 150,000 ₸, from one week. The processor does not silently create new products from the price list; it sets them aside for review.
More 1C services
Related tasks that usually go together.
1C developer
1C tasks with an estimate before work starts.
External 1C data processors
Imports, bulk operations, catalog cleanup.
1C integration
Exchange with your website, app and external systems.
1C Kaspi integration
Products and stock to the marketplace without duplicates.
Server for 1C
Hosting a grown database on a server in Kazakhstan (in Russian).
Send a request
Describe the task: we reply within one business day and quote before any work starts.