"We moved to a new system and lost the supplier data." We have been hearing that sentence, with different variations, for 30 years. Sometimes it is the suppliers, sometimes the clients’ current accounts, sometimes the last eight years of purchase history that the company needed right then to argue over a price list.
The problem is almost never the new system. It is the migration: it was rushed, it was validated by counting records instead of looking at data, and nobody left a way back.
At KeySistemas we have been migrating data into management systems since 1995. We do it in stages, with a test environment before touching production, and with a rollback plan written in advance.
Not everything in your old system is worth the same, and not everything migrates the same way. These are the five things an Argentine SME always has to bring over:
Legal name, tax ID, tax status with ARCA (the Argentine tax authority), delivery address, payment terms, assigned salesperson, credit limit. Without the tax status migrated properly, the first document you issue in the new system comes out wrong.
Codes, descriptions, units, VAT rate, barcodes, equivalences, categories. This is when the duplicates show up: the same product loaded three times under three different codes because three different people created it. It gets cleaned before migrating, not after.
Client and supplier balances, with the make-up of each balance: which documents form it, which are partially settled, which cheques are on hand. Migrating only the final balance is what later leaves you arguing with a client unable to show where the number comes from.
The same data as clients, plus purchase terms, cost lists and open orders. It is what we have seen left out most often, because "there are only a few suppliers and we will type them in by hand". Then it turns out there were 340 of them and nobody remembered the terms that had been agreed.
Sales, purchases, stock movements, collections and payments from previous years. It is the first thing cheap migrations throw away, and it is what lets you compare one season against the last. If you start the new system with the history at zero, you lost your own memory.
Before touching anything, we survey where the data lives, in what format, which parts are critical and which are accumulated junk. Out come the duplicates, the clients created twice and the tables nobody has used in years. Typical duration: 1 to 2 weeks.
Database, configuration files, custom reports, documentation. Stored off the machine where the current system runs, and tested: a backup that was never restored is not a backup.
The first migration goes to a test environment, never to production. That is where the real problems appear: fields with no equivalent, dates in different formats, balances that are off by cents.
Matching record counts prove nothing. We check that the reports you use every day give the same result as in the old system, that current accounts reconcile document by document, and that your team can do their normal work in the new system.
Only once the test run is 100% validated do we do the definitive migration, and always at a moment where a surprise will not stop your operation: a long weekend, a slow season, a month-end already closed.
A realistic total for a company of 20 to 50 employees: 2 to 3 months from kick-off until everything runs smoothly. One-week migrations are the ones that cause problems for two years afterwards.
No migration is approved without a written way back. Ours has four points:
Rolling back after a failed migration is harder than it looks, above all if new data has already been loaded. That is why plan B is defined beforehand, not when it is needed.
The old system stays running and reachable for at least two weeks after the switch, in read-only mode.
Backups are versioned and come with a restore that has already been tested, not just stored.
There is a written rollback procedure: who runs it, in what order, and up to what point in the day you can go back without losing newly entered data.
Your team knows in advance who to call and what to do if something does not work, instead of improvising on Monday morning.
Generally yes. We work with exports from commercial management systems, old custom developments, Access databases, Excel spreadsheets and, in the worst case, reading the database directly. What defines the difficulty is not the brand of the system, it is how tidy it is inside.
The actual switch is usually one day, and often less. All the heavy work happens beforehand, in the test environment. The final migration is the last run, already rehearsed.
Yes. Most of the migrations we do go into KeyGestión, but the migration service is hired separately and commits you to nothing.
Learn moreIt gets solved anyway, by reading the database directly. It means more survey work, it is not a blocker.
It shows up in the stage 1 audit and what to do gets decided before migrating: clean it, merge it or leave it out. Migrating the mess as is, is the fastest way to open a new system carrying the problems of the old one.
Tell us what you have today and what you want to keep. We look at your specific case and tell you what can be migrated, how long it takes and what the risks are, before you commit to anything.
Let’s talk about your migrationDirect attention from San Martín, Mendoza. No call centres, no ticket queues.