An electrical supplies distributor in Casablanca, 45 staff, decides to replace the management software installed in 2012 with a modern ERP. The integrator’s quote runs to a page and a half, and the line labelled “data takeover” sits there at MAD 12,000, fixed price, two days of work. The current database holds 9,400 customer records, twelve years of invoices, delivery notes scanned onto a network share, and a “Notes” field where the sales team spent a decade writing everything the software had no room for.
The case is invented, but its shape turns up in nearly every switchover. Those two billed days cover a technical transfer. They do not cover the decision that actually drives the budget: what deserves to move into the new system, in what form, and who settles the question when the two data models look nothing alike.
The day “changing software” becomes a data project
Three very different things carry the word “data” in an IT quote. Integration connects live systems that keep exchanging records permanently, with its own cost logic, which we covered in our piece on real data integration costs and timelines in Morocco. A warehouse consolidates copies for analysis, with no obligation to reproduce operational history faithfully. Migration is something else: a single transfer, on a fixed date, after which the old system goes dark.
That finality changes how the project has to be run. A badly configured integration flow gets fixed the next morning. An incomplete migration surfaces six weeks later, when a customer disputes a 2021 invoice and nobody can find it outside a backup no workstation can still open. The software project has a go-live date; the data project has to start earlier. And if the functional scope is still open, the ERP or CRM question gets settled first, because it decides what there is to migrate.
What you actually migrate: customers, history, documents, relationships
At our distributor, the scope breaks into four layers that carry neither the same value nor the same cost.
Master data first: customers, suppliers, items, price lists, chart of accounts. That is the foundation, and that is where cleanup earns its keep. Then transactional history: orders, invoices, payments, stock movements. Third layer, documents, usually stored outside the software: invoice PDFs, signed delivery notes, contracts, attachments. Finally the relationships, the layer everyone forgets: which contact belongs to which account, which payment settles which invoice, which item replaced which discontinued one.
The first three layers move with method. The fourth produces the unpleasant surprises. A 9,400-customer base imported cleanly but stripped of its links gives you a new ERP where every record exists and no outstanding balance is correct. Decide layer by layer, with a simple rule: master data and open balances become live data, older history becomes read-only or archive, and that trade-off gets written down.
Cleanup before the transfer: duplicates, formats, orphan records
A twelve-year-old database always carries the same defects. The same customer entered three times as “SARL ATLAS”, “Atlas Distribution” and “ATLAS DIST.”, with invoices spread across all three records. Phone numbers written as 06, as +212 6 and as 00212. An ICE number filled in for one customer in two, sometimes inside the “Notes” field. Creation dates of 01/01/1900 because the field was mandatory. Deactivated items still linked to open orders.
CRM and ERP data cleanup is not a technical job, and that is exactly what makes it expensive. A developer can detect that three records resemble each other. He cannot decide which one to keep, or whether the two Atlas entries are one company or two branches with separate accounts. That call belongs to the sales administrator and the accountant who have handled those files for years, and their time belongs in the schedule just as much as the vendor’s.
The sequence that works: extract, profile (count duplicates, empty fields, out-of-format values), produce correction lists by theme, have a named business owner approve them, then reimport. Fixing things directly in the old system disrupts daily operations, whereas a staging file lets you repeat the exercise as often as needed. It follows the same logic as a data quality audit before a BI project, and if you have already run one, much of the work carries over.
Field mapping: why two systems never talk to each other directly
Two pieces of software never store the same information the same way. The old one has a single “Address” field, the new one separates billing from delivery. The old one stores “30 days end of month” as free text, the new one expects a payment term code from a closed list. The old one makes no distinction between prospect and customer, the new one does.
ERP field mapping is therefore an exercise in decisions, not translation. For every source field there are three outcomes: direct transfer, transformation under a written rule, or deliberate abandonment. The third is perfectly legitimate, provided the person who uses the field daily signs off on it rather than the project manager alone.
Two items deserve particular attention. Catch-all fields first: that famous “Notes” column mixes commercial terms, contact details, disputes and personal remarks. Sorting it by hand across 9,400 records is unrealistic, moving it wholesale into a free-text note is acceptable, but you have to say plainly that the content will not be searchable in any structured way. Customer codes next. If the new ERP renumbers them, every paper document, dunning letter and past email thread points at references that no longer exist. Keeping the legacy code in a dedicated field costs almost nothing and spares you months of confusion.
Data migration Morocco: the 2026 price ranges
Five variables set the price: how many entities you carry over, whether the old system offers a clean export or an API, how many years of history you keep, the document volume, and how many business decisions need arbitration. A well-structured 200,000-row database costs less than a dirty 8,000-record base with no documented schema. The orders of magnitude seen for a Moroccan SME in 2026:
- Simple CRM migration (contacts, companies, opportunities, no documents, usable CSV export): MAD 15,000 to 40,000.
- SME ERP switchover (full master data, 3 to 5 years of history, customer and supplier balances, a few thousand documents): MAD 60,000 to 180,000.
- Undocumented legacy system (proprietary database, access only through screens or partial exports, multiple sites, document archive to recover, custom developments): MAD 180,000 to 450,000.
Those figures match day rates of MAD 3,000 to 6,000 depending on the profile involved. The most frequently forgotten part of data migration cost, though, is internal: if two business users spend fifteen days on cleanup and acceptance testing, that is a month of effort nobody budgeted. One last habit worth keeping, when a vendor quotes a fixed “data takeover” package, ask in writing what sits inside it. In most cases it covers master data, not history, not documents, not corrections.
The dual-entry period, and the moment it breaks
Between shutting down the old system and trusting the new one lies a grey zone. The usual practice is to run both in parallel: enter the order in the old ERP, then in the new one, then compare. The intention is sound, the announced duration almost never is.
Dual entry holds for one to two weeks. Beyond that it degrades quietly: a rushed salesperson enters data in one system only, then copies across only the straightforward cases, and after three weeks the two databases have drifted apart without anyone raising it. The classic breaking point is month-end close, when finance has to name one system of record to invoice from.
Two more honest approaches exist. Either a clean cutover across a freeze window: stop entries Friday evening, migrate, run the controls, restart Monday, with a written fallback plan. Or a cut-off date, where history stays readable in the old tool for six to twelve months and only open transactions move. If you insist on a parallel run, confine it to one process and fix its end date from the outset.
CNDP and historical data: what to purge instead of transferring
A migration is the best opportunity in a decade to stop keeping what you no longer have a reason to keep. Law 09-08 requires a stated purpose and a proportionate retention period. Moving data into new software extends its life and renews your responsibility for files you should have closed.
In our invented case the purge candidates are obvious: prospects never converted since 2016, unsolicited CVs, records of employees who left more than ten years ago, bank details sitting in plain text in a free field, identity documents scanned “just in case”. Every item deleted before the switchover is an item you do not map, do not clean and do not pay for. Applicable periods vary by data type, we gathered them in our article on CNDP retention periods, and for borderline cases, check the CNDP website.
Formalise the operation: a list per category, the retention period chosen, the justification, the execution date, approved by management. Think about your filings too. If your processing activities were declared with the old tool, changing software and hosting may require an update, particularly if the data leaves Morocco. Confirm that before the switchover, not after.
The reversibility test before you flip the switch
No migration should reach production without being played through end to end at least once on a copy. The dress rehearsal measures three useful things: how long the transfer really takes, how many anomalies need fixing, and whether you can actually roll back if the day goes badly.
Acceptance controls are decided beforehand, not afterwards. A handful is enough if they are the right ones: active customer count before and after, total customer receivables to the centime, invoice count per year, manual review of the twenty largest accounts by a sales manager. A non-zero gap on receivables is not a detail to regularise later, it usually means a link broke somewhere in the mapping.
On reversibility, three requirements belong in the contract: a complete and tested backup of the old system, guaranteed read access for six to twelve months, and a raw export of your data in an open format, held by you. That last point is your insurance if the relationship with the previous vendor sours, a common scenario we cover in our guide on switching IT provider in Morocco.
Before you sign the “data takeover” line
Ask for three deliverables before work starts: the scope layer by layer, the mapping document, and quantified acceptance criteria. A provider who will not write them down will bill you for those decisions later, on a time and materials basis. The Arrowlancer data team scopes and runs this kind of migration (audit, cleanup, mapping, purge, acceptance controls) alongside an ERP, CRM or cloud project and alongside the software integrator, and the scope of our data work is set out on our services page. If your switchover is planned for the coming months and that quote line looks too short, let’s talk it through before you sign.