Meridian Sourcing is an agent in Egypt working on a hybrid mix of Make to Order and Make to Stock business for two European buyers, earning a 5% commission on order value. Its own tracking spreadsheet has reached the point Lesson 5.3 describes: several risk factors present, several buyers' data mixed in one file, and formulas that no longer match row to row. Moving that data straight into a new shared system without preparing it first does not fix the underlying problem; it only moves the same uncontrolled data into a system that looks more official.
This lesson gives you a working method for the two things that must happen before a move: cleaning the data itself, and agreeing the working method the new system will actually be used under. A system is only as reliable as the data it starts with and the habits people keep once it is running.
You need: Lesson 5.3 on recognising a spreadsheet's control risk, plus a basic understanding of a shared order record and an agent's role between a factory and a buyer.
By the end of this lesson you can:
Not covered here: choosing or configuring a specific software product. This lesson stays vendor-neutral and covers the business preparation any shared system needs, regardless of which one is chosen.
| Term | Meaning |
|---|---|
| Data migration | Moving existing records from an old working method into a new one, cleaned and checked before they are trusted there. |
| Shared business system | A controlled, generic business application used by more than one department or company at the same time, instead of separate personal files. |
| Data cleansing | Checking and correcting existing records for duplicates, missing fields and inconsistent formats before they are loaded into a new system. |
| Access right | Permission that allows a specific role to view, enter or change a specific piece of business information. |
| Change control | The agreed process for approving, recording and communicating a change to controlled business information before it takes effect. |
Moving data into a shared system solves an access or scale problem only if the data being moved is trustworthy. Duplicate records, missing fields and inconsistent formats do not disappear when a file is uploaded into a new system; they become duplicate, missing or inconsistent records in a system everyone now expects to trust more, which can be worse than the spreadsheet it replaced. A working method agreement — who enters what, on what schedule, with what approval — must exist before the first record is entered, or the same uncontrolled habits simply continue inside the new system.
Readiness, not availability, is what should trigger a migration date.
| What can differ | The shapes you will meet | Why it matters to you |
|---|---|---|
| Export order under Make to Order | A single buyer's confirmed order data is usually the cleanest to migrate, since each order is a distinct, well-bounded record. | Fewer, larger, well-defined records make data cleansing faster, but the working method agreement still matters, since more than one department will now read the same system. |
| Domestic replenishment under Make to Stock | A standing forecast's data has usually grown through many small edits over a long period, making duplicates and inconsistent formats more likely. | Cleansing here often takes longer than the migration itself, because the same reorder line may exist under slightly different names or units across old copies. |
| Hybrid mix handled through an agent | An agent's file mixing several buyers' order types in one place needs its records separated and re-checked per buyer before a shared system can trust any of them. | A system that lets several buyers view only their own data depends entirely on the migrated records being correctly attributed; a mixed, uncleaned file breaks this from day one. |
| A single contributor versus a team | One person's own working habits transfer easily to a system only they use; a team's habits need explicit agreement before several people rely on the same shared record. | Without an agreed method, old habits such as editing a field nobody else was meant to touch simply move into the new system unchanged. |
| Different product families | Socks, knit-to-garment, terry and bedding records each carry different fields, but every one needs the same cleansing checks before a migration. | The fields differ; duplicate, missing and inconsistent data are risks in every product family. |
Meridian Sourcing tracks a hybrid mix of order types for two European buyers, taking a 5% commission on order value, and uses Order A's own fixed figures (15,000 T-shirts, agreed FOB USD 3.20 per piece, total order value USD 48,000) as the reference transaction shape for its own commission calculation. Delta Garments is introducing a shared business system that Meridian, the factory and both buyers will all use to track order status, and Meridian's own spreadsheet data needs to move into it.
Before agreeing a start date, Meridian checks its own data for duplicate order rows created when the same order was re-entered after a specification revision, missing ship-date fields on older rows entered before that field existed, and inconsistent buyer-name spellings that would otherwise show as different buyers in the new system. Separately, Meridian, Delta Garments and both buyers agree who enters production-status updates, who confirms commercial fields, and what happens if a field looks wrong after the system goes live. Only once both checks are complete does Meridian agree a migration date with Delta Garments.
The worked numberMeridian's spreadsheet holds order records built up over time. A data-cleansing check finds the following before migration begins.
Thirteen of forty rows, close to one-third, needing correction before migration is not evidence Meridian's spreadsheet was badly run; it is the ordinary result of any working file built up gradually over time without a scheduled cleansing check. Migrating all 40 rows unchecked would have carried these 13 problems directly into the new shared system, where two buyers and a factory would then all be reading them as if they were correct.
That date feels natural, because it is the date everyone has been waiting for, and delaying it can feel like resistance to change. The cost appears afterwards, when duplicate or inconsistent records start producing visibly wrong figures inside a system two buyers now expect to be more reliable than the spreadsheet it replaced, which damages trust in the new system faster than the old spreadsheet's known problems ever did.
The better rule is simple: treat the system's availability date and the migration's readiness date as two separate dates, and move only once both data cleansing and the working method agreement are actually complete.
Moving into a shared system is like moving into a new office. If you carry unsorted, damaged boxes into the new office and never agree who is responsible for which room, the new office does not fix any of that; it just gives the same mess a nicer address. Before the move, sort the boxes, throw out the duplicates, and agree who is responsible for what once everyone is in the new space.
The same is true for data. Check it for duplicates, missing pieces and inconsistent labels before it moves, and agree who enters what and who approves a change before the new system goes live. The system itself cannot do either of these things for you.
Delta Garments announces that the shared system will go live in one week and asks every party, including Meridian Sourcing, to migrate its own data by that date. Meridian has completed its duplicate and missing-field checks but has not yet resolved the inconsistent buyer-name spellings across its older rows.
Should Meridian migrate its data on the proposed date? Decide before opening the answer.
No. Meridian corrects the three inconsistent buyer-name rows first, and migrates once that check is complete, even if this means missing the proposed date by a few days.
1. An inconsistent buyer name is exactly the kind of problem a shared system cannot self-correct. Once migrated, the new system would show one buyer's order history split across what looks like three separate buyers, which is harder to untangle after the fact than to fix in the source file now. 2. The working method agreement being ready is necessary but not sufficient; both data cleansing and the working method must be complete, and only one of the two conditions is currently met. 3. A short delay to finish three rows' worth of correction costs far less than migrating a known, identified problem into a system both buyers are about to start trusting more than the spreadsheet it replaces.
The date a system becomes available is not the same fact as the date the data and the team are ready for it; Meridian's own readiness check, not Delta Garments' proposed date, should decide when Meridian's data actually moves.
Order A's fixed total order value, USD 48,000, and Meridian's 5% commission on it show the transaction shape Meridian's own tracking file exists to record.
A duplicate or misattributed order row does not usually change the commission calculation itself, since the underlying order figures stay the same; its real cost is the time spent, after migration, tracing which of two duplicate rows is correct, or reassigning a wrongly split buyer history back into one record, inside a system that is now shared by more people than the old spreadsheet ever was. Cleansing thirteen rows before migration, as in the worked number, is a bounded, one-time task; untangling the same thirteen problems after they have already been acted on inside a live shared system is not.
Use the T17-C05 Data governance decision tool workbook. On the Keep, improve or replace sheet, record whether data cleansing is complete and whether a working method has been agreed, each as 1 (yes) or 0 (no); the sheet calculates migration readiness only when both are 1. Apply it first to Meridian Sourcing's own migration, then to a shared-system move you are preparing at work.
[Download the Data governance decision tool workbook](../../templates/T17-C05-data-governance-decision-tool.xlsx)
1. Why does Meridian Sourcing check its own order records for duplicates and inconsistent buyer names before migrating, rather than migrating first and fixing problems inside the new system?
2. A different agent's file has 25 order rows, with 2 duplicates, 1 row with a missing field, and 0 inconsistent names found during a data-cleansing check. How many rows need correction before migration?
| EN | AR | FR | TR | Meaning |
|---|---|---|---|---|
| Data migration | ترحيل البيانات | Migration des données | Veri taşıma | Moving existing records from an old working method into a new one, cleaned and checked before they are trusted there. |
| Shared business system | نظام عمل مشترك | Système d'affaires partagé | Paylaşılan iş sistemi | A controlled, generic business application used by more than one department or company at the same time, instead of separate personal files. |
| Data cleansing | تنقية البيانات | Nettoyage des données | Veri temizleme | Checking and correcting existing records for duplicates, missing fields and inconsistent formats before they are loaded into a new system. |
| Access right | حق الوصول | Droit d'accès | Erişim hakkı | Permission that allows a specific role to view, enter or change a specific piece of business information. |
| Change control | ضبط التغيير | Contrôle des changements | Değişiklik kontrolü | The agreed process for approving, recording and communicating a change to controlled business information before it takes effect. |
Next you will bring the whole course together into one decision tool that scores a spreadsheet's risk and readiness and recommends whether to keep, improve or replace it. Back to the course map