Migration is not a technical project. Loading data into a new system is the easy part; the work is deciding what is true when three spreadsheets disagree. Developers who accept that early finish in a month. Developers who treat it as an IT task discover the disagreements at go-live, when they become urgent.
What actually gets migrated
| Data set | Source | Difficulty |
|---|---|---|
| Projects, buildings, floors, units | Inventory sheet | Low, once duplicates are removed |
| Unit attributes and prices | Price list | Medium — computed prices must be reconstructed as rules |
| Buyers and contacts | Booking file, CRM, phone contacts | Medium — deduplication is the work |
| Bookings and agreements | Booking register | Medium |
| Payment schedules | Kisti sheets | High — often per-buyer variants that must become templates |
| Receipts and outstanding balances | Accounts and collection sheets | High — this is where the reconciliation happens |
| Land and JV records | Legal files | Medium, low volume, high value |
| Contractor and supplier data | Accounts | Low |
Step one: freeze and clean
Before any mapping, agree three things: the cut-off date, the single authoritative source for each data set, and one person who decides when sources disagree. Then clean at source — in the spreadsheets, where your team already knows the data. Cleaning after loading means doing it twice.
The most common findings at this stage: units that exist in the price list but not the inventory sheet, buyers with two records and different balances, and bookings whose payment schedule was edited but whose agreement was not.
Step two: map the fields
Mapping is mechanical except in one place — payment plans. In a spreadsheet, every buyer's schedule can be different, because editing a row costs nothing. In a system, schedules come from plans. The migration therefore has to answer: how many genuinely distinct plans exist? Usually the answer is four or five, plus thirty buyers whose schedules were edited by hand. Those thirty become restructures with a documented reason, which is what they always should have been. See building a schedule that does not live in Excel.
Step three: opening balances that reconcile
For each buyer, the migration must produce: total charged to date, total received to date, and the outstanding balance — and the sum of those has to match your accounts. This is the moment the migration either succeeds or quietly fails.
Produce a reconciliation report that shows, per project: number of units, number of bookings, total contract value, total received, total outstanding, in both the old and the new system, with the differences listed line by line. Every difference must be explained before go-live. "It is close enough" is how a developer spends the next two years distrusting their own system.
Step four: the parallel run
Run both for one full month, including a month-end close. At the end, compare three reports: collection for the month, outstanding by ageing bucket, and the buyer ledger for ten randomly chosen buyers. If they agree, migration is proven. If they do not, you have found the problem while the old process is still running — which is the entire point.
Parallel running is double work for one month. Skipping it moves that work to go-live, when it is triple.
Step five: cut over and lock
After cutover, the old spreadsheets must become read-only. This is a discipline problem rather than a technical one, and it is the most common cause of a failed implementation: a collection officer keeps a personal sheet "just in case", and within two months there are two versions of the truth again. The old files should be archived, not deleted, and access should be read-only from cutover day.
What to do next
Before choosing a vendor, do one thing: produce the reconciliation numbers for one project — units, bookings, contract value, received, outstanding — from your current spreadsheets. However long that takes is your migration timeline, and whatever does not reconcile is the real work. Then walk the migration through on your own data.