TMS Data Migration

TMS data migration is the work of moving your treasury data — master data first, then open positions and live deals — into a new treasury management system so that the new system produces exactly the same positions, cash flows and valuations as the old one on the day you cut over. It sounds like a loading exercise. It isn't. It's a data-quality exercise wearing a loading exercise's clothes, and it's where a well-run TMS implementation quietly goes wrong.

I've watched programmes that nailed the design and the bank connectivity still stumble at go-live because the data underneath wasn't owned early enough. So this is the phase I'd tell you to worry about first, not last.

What actually moves

Not everything, and not in one go. Migration has a strict order, and the order is the point.

Master (static) data first. This is the reference layer everything else points at:

• Bank accounts and house banks — the accounts you hold, at which banks, with which identifiers.
• Counterparties and business partners — the banks, brokers and internal entities you deal with.
• Instruments — the definitions of the products you trade (loans, deposits, FX, swaps).
• Standing settlement instructions (SSIs) — where money actually goes when a deal settles.

Then the transactional layer — open positions and live deals: the loans still outstanding, the deposits not yet matured, the FX and swaps still on the book. Each of these carries its correct opening valuation and accrued interest, not just its original trade terms.

Then a decision about history. How many years of closed, matured, settled transactions do you drag along? Usually the answer is: far less than people first assume.

Master data is the whole game

Here's the principle that saves programmes: migrate master data clean, and prove it clean, before anything references it.

A deal in a TMS is mostly pointers. It points at a counterparty, a bank account, an instrument, a settlement instruction. If the counterparty record is wrong, every deal that references it is wrong — silently, and in a way that doesn't surface until a payment goes to the wrong place or a position won't reconcile. A single dirty bank account or a duplicated business partner doesn't cause one problem; it seeds hundreds, each traceable months later to a record nobody cleaned.

"

Dirty static data doesn't corrupt one deal. It corrupts every deal that points at it — and you find out at the worst possible time.

This is why static-data quality is the whole game. You cleanse it, de-duplicate it, and validate it before load — not "to fix later" once positions are already sitting on top of it. The same discipline shows up in why TMS implementations fail: the root cause is almost never the load mechanics. It's that no one owned the data.

Open items and opening balances

Migrating a live deal is not copying a row. It's reconstruction.

The test is simple and unforgiving: after migration, the new system's future cash flows, position and valuation for that deal must be identical to the legacy system's as of the cutover date. Same principal and schedule, same accrued interest, same mark-to-market. If your legacy system says a swap is worth a certain amount today and generates a certain stream of payments, the new system must agree — to the cent.

That means opening balances and opening valuations are migrated deliberately, not derived hopefully. You're not re-deriving history in the new system; you're seeding it with a correct starting point so that from cutover forward it computes the same answers the old system would have. Get one accrual convention or one valuation date wrong and the position drifts from day one.

The approach: extract, cleanse, load, reconcile

The mechanics are conventional. The discipline around them is not.

1. Extract the data out of the legacy system and any spreadsheets it quietly depends on.
2. Cleanse and transform — de-duplicate, correct, and map legacy structures to the new system's model. This is where most of the real effort lives.
3. Load into the new system, master data before transactional data, always.
4. Reconcile — and this is the step teams under-budget. Tie every balance, position and valuation back to the source and resolve every break.

The reconcile step is what turns a migration from an act of faith into an act of evidence. And the strongest form of it is a parallel run: for a period before cutover, both the old and new systems process the same reality, and you compare their output. A real month-end in both. A real valuation in both. When they produce the same numbers across real cycles, you've earned the right to trust the new one. Until then, you haven't. This is the same reconcile-and-prove muscle that underpins data migration for finance systems generally — treasury just punishes a mismatch faster, because a wrong position is visible the next morning.

What about history?

The instinct is to bring everything. Resist it.

You generally don't migrate deep transactional history into the operational TMS. The new system needs enough to compute today's positions and forward cash flows correctly — the open book and its opening state — not fifteen years of settled deals cluttering the system it has to run on tomorrow. For the history itself, keep the legacy system readable in read-only mode for a defined period, or archive it somewhere you can query for audit. Then start the new system clean.

This keeps the transactional system lean and keeps the migration scope honest: every year of history you insist on loading is data you must also cleanse, map and reconcile — for records that are already closed.

Where it quietly goes wrong

If you take one thing from 18 years of watching these: data migration is rarely hard because loading is hard. The load is a solved problem. It goes wrong because nobody owned data quality early, so cutover weekend arrives with static data migrated "as-is to fix later," positions that don't reconcile, and a team discovering at the worst possible moment that the new system and the old one disagree.

The documentation makes it a tidy box on a plan — one phase, a few weeks, "migrate and reconcile data." The reality is a thread running through the whole programme. Name a data owner on day one, cleanse master data long before load, treat reconciliation as evidence rather than a formality, and prove the whole thing with a parallel run. Do that, and cutover is boring. Skip it, and cutover is the moment you discover what you should have owned six months earlier.

For where this phase sits in the wider programme, see the implementation guide.

Part of the Treasury Management Systems guide. If you found this useful, the newsletter sends one practical finance-systems pattern every two weeks — real SAP, treasury and delivery notes from 18 years inside enterprise finance.