In this guide 6 sections
Map every field between the two systems, including units, dates and required values, and test with real records, including the ugly ones. Build an error queue. Agree a rollback. Then run both systems in parallel, and name who watches the first live week and what that person does when a message fails.
Map the fields before anyone writes code
Open both systems and list every field that will move, and put source field, target field, data type and whether it is required on one sheet. Gaps appear fast. A target may insist on a postcode when the source never captured one, and every such gap needs a default or a fix.
Decide the match key for every object. A customer can be matched on tax number, email address or an internal customer code, and each choice fails differently when two branches share a mailbox. Pick one, write it down, and run a query that proves the value exists, and is unique, on every existing record.
Mark each field one way or two way. Two way fields need a rule for which system wins when both are edited, and a note of who settles a tie.
- Source field, target field, type and length
- Required in the target but blank in the source
- Match key for customers, items and orders
- Direction and winner for each shared field
Settle units, dates and codes
Small format gaps cause the worst quiet errors. One system stores weight in kilograms and the other in pounds, while one writes dates as day, month, year and the other adds a time zone.
List every code table too: payment terms, tax codes, units of measure, order statuses, and build a translation table that maps the sender’s value to the receiver’s. Anything unmapped should be rejected loudly, not guessed.
Check rounding on prices and quantities. A line total that differs by a rounding fraction, repeated across thousands of invoices, becomes a reconciliation headache for the accountant at every month end.
Test with real records and plan for failure
Build the test set from real records. Clean examples hide the edge cases. Include a customer with an apostrophe in the name, an order with forty lines, a cancelled invoice and a record with a blank phone field.
Every message that fails needs somewhere to wait. An error queue holds the rejected record, the reason and the time, so a person can fix the data and replay the message instead of rekeying it.
Decide which failures alert and which retry. A timeout can retry. A rejected tax code needs a human who understands the tax rule behind it, and the alert must name that role and say which record failed.
- Odd characters, long names and empty optional fields
- Cancelled, edited and credit-note records
- A record sent twice to test duplicate handling
- An outage on each side to see the queue behave
Agree rollback and run in parallel
Write the way back before going live. Which switch stops the link? Which records created since go-live stay in the target, and which are cleaned out before the old process takes over again? Name the person who may call the rollback.
Run both ways of working side by side for a short period, and staff keep doing the old manual step while the integration also runs. At the end of each day, compare counts and totals between the two systems, and keep the comparison sheet, signed by the person who owns the ledger. Differences are the useful output.
Each difference points to a mapping rule. It is either wrong or missing.
Staff the first week of live traffic
Name one person who checks the error queue every morning and again before close, and write that duty into their job card for the first week. Give them the vendor contacts, the replay steps and the authority to pause the link without asking anyone, even in the middle of a customer call.
Keep a log of every fault. Record its cause and its fix. By the end of the week, the log shows the two or three patterns that deserve a permanent rule in the mapping sheet. Hold a review on day seven, then close the parallel run only when totals have matched for several working days in a row.
Double entry is tedious. Resist ending the run early.
Go live integration checklist
A two page checklist in five blocks. First, a field mapping table. Second, a format and code translation table. Third, a test record list with expected results. Fourth, a rollback card naming who decides. Last, a first week log with columns for date, fault, cause, fix, replayer and the time the queue was cleared, so the pattern behind each failure shows.
Open a blank worksheet to printQuestions owners ask
How long should a parallel run last?
Long enough to cover a full cycle of the process, such as a month-end close for accounting links or a complete pick, pack and dispatch run for orders. For order flows, a week is common. Longer is safer.
Who owns the field mapping sheet?
A business owner should sign it off, since they know what each field means and which values the warehouse or the accounts team will reject. A developer keeps it current. Treat any later change to the sheet as a change request, with a date, a name and a reason against it, so the sheet shows how the mapping drifted.
What should the error queue show?
The failed record, the system that rejected it, the plain reason, the time and a replay button or step, plus the name of whoever fixed it and when. A storekeeper or an accounts clerk without technical skills should be able to read every line without calling the developer.
Can we skip testing with real data?
It is risky. Clean examples hide the edge cases that break live syncs, so test with a copy of real records, masking personal details if the test system is shared.