How to migrate from a legacy TMS to Kyriba: A practical guide

How to migrate from a legacy TMS to Kyriba: a practical playbook

A practical guide for evaluating, planning, and executing a transition from a legacy TMS to Kyriba. This playbook focuses on the decisions that reduce migration risk, protect treasury operations, and help teams get more value from the new platform.

At a glance: what makes a TMS migration successful?

A successful TMS migration starts early, treats bank connectivity and ERP integration as critical paths, involves IT and end users from the outset, separates Day 1 requirements from post-go-live improvements, and uses the transition to redesign broken processes rather than reproduce them.

What is a TMS migration and what does this guide cover?

A treasury management system, or TMS, is software used to manage cash visibility, liquidity forecasting, payments, bank connectivity, debt, investments, foreign exchange, and related treasury controls. A TMS migration is the process of moving these capabilities, data, integrations, and workflows from one platform to another.

Treasury teams rarely migrate TMS platforms simply because they want a like-for-like replacement. More often, they migrate because the current operating model has become too risky, too manual, too fragmented, or too expensive to maintain.

This playbook explains how treasury, finance, IT, and implementation teams can plan and execute a move from a legacy TMS to Kyriba. It covers the practical decisions that determine success, including when to start, how to manage renewal pressure, which workflows to replicate or redesign, how to coordinate bank connectivity and ERP integration, and how to prepare users for go-live.

Why do treasury teams migrate from a legacy TMS?

Most migrations begin with a business trigger. Common triggers include:

Renewal pressure. A legacy contract is approaching expiration, pricing has changed, or the customer wants to avoid being locked into another multi-year cycle.

Legacy support issues. The current platform is difficult to support, slow to change, dependent on scarce expertise, or no longer aligned with the company's treasury needs.

Spreadsheet reliance. Critical cash positioning, forecasting, payment tracking, or reporting processes are being performed outside the system in spreadsheets.

ERP change. An SAP, Oracle, Workday, NetSuite, Microsoft Dynamics, or broader finance transformation creates a natural opportunity to modernize treasury connectivity and workflows.

Bank connectivity pain. Bank onboarding takes too long, formats are inconsistent, payment processes are fragmented, or cash visibility depends on manual bank portal activity.

Control and audit pressure. Treasury needs stronger segregation of duties, better approval workflows, more reliable audit trails, or reduced exposure to payment fraud.

Growth or complexity. More entities, currencies, banks, regions, or payment volumes have made the current operating model too manual or too fragile.

These triggers create urgency, but successful migrations also require realistic planning around contract deadlines, bank onboarding timelines, IT bandwidth, data quality, user adoption, and the daily operating rhythm of treasury. The goal is not simply to replace a system, but to reduce risk, improve visibility, strengthen controls, and lower the operational burden on treasury, finance, and IT.

What is the guiding principle for a successful TMS migration?

Design for where you’re going, not just where you’ve been.

The temptation in any migration is to replicate what exists. "Just move it over." That approach preserves every inefficiency, workaround, and broken process from the legacy system and buries them inside Kyriba.

The better approach: distinguish between what works and should be replicated, and what is broken and should be redesigned. The implementation period is an important opportunity to modernize processes, strengthen controls, and improve automation.

Which processes should you replicate and which should you redesign?

• Replicate what works. Rebuild proven processes, payment formats, bank connections quickly and accurately.

• Redesign what doesn’t. Broken workflows, manual workarounds, and legacy limitations should be identified in blueprinting and solved in Kyriba, not carried over.

What should you evaluate in the destination TMS?

A migration is only as valuable as the destination. Evaluate the new TMS not only for functionality, but also for its bank connectivity, ERP integration, security, implementation readiness, scalability, and experience supporting treasury teams. These factors can reduce migration risk, simplify operations, improve visibility, and enable capabilities the legacy environment could not support. Kyriba addresses these requirements through its cloud platform, connectivity network, integration capabilities, and treasury functionality.

What is Kyriba?

Kyriba is a cloud-based liquidity management platform that supports cash visibility, forecasting, payments, connectivity, risk management, and related treasury workflows. Kyriba’s global footprint includes:

The bank connections, ERP integrations, and payment formats you need are likely already established and tested. A meaningful portion of your banks may already have Kyriba connectivity, which can mean fewer net-new builds, more reusable patterns, and less uncertainty in the project plan.

That matters because migration risk usually concentrates in a few places: bank onboarding, payment formats, ERP integration, workflow redesign, data mapping, controls, and user adoption. These capabilities can help reduce risk with connectivity, repeatable implementation patterns, configurable workflows, strong security and compliance foundations, and a post-go-live platform that continues to support automation, visibility, and control improvement.

How should you evaluate TMS security and compliance?

Use this list to evaluate TMS security and compliance posture:

• ISO 27001 Certified (Global Standard for Information Security Management Systems)

• SOC 1, SOC 2, and SOC 3 Type II Reports (Security, Availability, and Confidentiality)

• SWIFT Compatible Application with audit-ready reporting and transaction logging

• TISAX Certified (Trusted Information Security Assessment Exchange)

• GDPR compliant and Data Privacy Framework (DPF) certified

• Hosted globally on Amazon Web Services with industry-leading RTO and RPO

• Powered by Databricks for AI and data infrastructure

For a corporate migrating from a legacy system, this compliance posture can support stronger controls during and after the transition.

What capabilities should a modern TMS provide?

A modern TMS should provide the following capabilities:

• Real-time cash position and liquidity visibility across all entities and banks

• AI-powered cash forecasting and scenario planning

• Automated payment fraud detection in real time

• ERP-native connectivity (SAP, Oracle, Workday, NetSuite, Microsoft Dynamics)

What business outcomes can a TMS migration deliver?

The strongest migration business cases are not built on technology replacement alone. They connect the move to measurable treasury and finance outcomes.

• Risk reduction. Moving away from unsupported, highly customized, or spreadsheet-dependent processes reduces operational fragility and key-person dependency.

• Better visibility. Centralized bank connectivity and real-time cash positioning give treasury a more reliable view of liquidity across entities, currencies, and banks.

• Stronger controls. Standardized workflows, segregation of duties, approval rules, audit trails, and fraud detection help reduce control gaps that often accumulate in legacy environments.

• Lower operational burden. Automation, reusable connectivity patterns, standardized payment templates, and ERP integration reduce manual work for treasury, finance, and IT.

• Greater scalability. A modern treasury platform makes it easier to add entities, banks, payment types, modules, and reporting capabilities as the business changes.

For senior stakeholders, the case is simple: a Kyriba migration is not only a project to avoid legacy-system risk. It is an opportunity to create a more visible, controlled, automated, and scalable treasury operating model.

How long does a TMS migration take?

Every treasury leader wants to know how long a migration will take, and it is often the first question they ask.

Typical range: 4 to 9 months

The timeline depends on:

• Number of banks and legal entities

• ERP complexity and number of integration points

• Volume and variety of payment formats

• Whether workflows are being replicated or redesigned

• IT resource availability

The timeline is shaped by build effort, decision speed, dependency management, and coordination across banks and internal teams.

Phase 1 — timeline & transition planning

How early should you start a TMS migration? Most organizations should begin planning at least four to nine months before go-live. The exact timeline depends on bank connectivity, ERP complexity, payment formats, data quality, and internal resource availability.

Starting too late is a common cause of migration delays and cutover risk. Legacy renewal dates create hard deadlines, and bank connectivity for major banks can take 8–12 weeks. Establish the timeline on Day 1 and work backward from the target go-live date, leaving time for testing and contingency.

Key actions

• Establish the legacy product timeline on Day 1. Identify the renewal/expiration date and work backwards.

• Confirm the "last drop" decision point, the date by which a go/no-go on migration must be made.

• Align the Kyriba implementation timeline so that go-live occurs before legacy expiration, with buffer.

• Identify blackout periods and critical business cycles (fiscal year-end, audit periods) and build around them.

• Maintain consistent urgency across all phases. Build and test as early as possible.

Phase 2 — workflow assessment & prioritization

How should you assess and prioritize treasury workflows? Assess each workflow by its business criticality, risk, dependencies, and Day 1 importance, then classify it as a must-have, post-go-live enhancement, or legacy workaround to redesign in Kyriba.

Classify every workflow into one of three buckets

Classification	Definition	Approach
Must-have (Day 1)	Business-critical on go-live	Replicate or redesign before cutover
Nice-to-have	Useful but not operationally urgent	Schedule for post-go-live optimization
Broken / legacy workaround	Exists to compensate for limitations in the old system	Do not replicate. Redesign in Kyriba

Key actions

• Map all current workflows in the legacy system during blueprinting.

• For each workflow, ask: *does this process work because it’s right, or because it’s what we’ve always done?*

• Prioritize Kyriba modules based on critical workflow dependencies.

• Document the "why" behind broken processes so they can be genuinely solved, not just moved.

Who should be in the room

Treasury operations, the treasury manager or director, IT, and at least one end user who runs day-to-day processes in the legacy system. If the person who actually uses the system is not in the room, the classification will be wrong.

Phase 3 — bank connectivity coordination

How should you manage bank connectivity during a TMS migration? Treat bank connectivity as a critical path from Day 1 by inventorying every bank and connection, confirming which setups can be reused, and assigning clear ownership for onboarding, testing, and cutover. Bank connectivity is consistently the longest lead-time item in any TMS migration. It is also the most frequently underestimated.

Key actions

• Notify all banking partners at project kickoff that a new TMS is being introduced and new connectivity must be established.

• Initiate bank connection setups immediately. Do not wait for blueprinting to complete.

• Identify which banks have existing SWIFT, h3H, or file-based connectivity with Kyriba to accelerate setup. With connections to 10,000 banks, many of your banks likely already have Kyriba connectivity.

• Build bank connectivity timelines into the overall project plan with realistic lead times (8–12 weeks minimum for major banks).

• Assign a named workstream owner for each bank. Bank-specific issues stall when no one owns them end-to-end.

Phase 4 — IT & ERP integration alignment

How should you plan IT and ERP integration? Plan IT and ERP integration from Day 1 by documenting every data flow, agreeing on the integration approach and ownership, and involving Treasury, IT, and end users in blueprinting. ERP connectivity is the backbone of any TMS. If ERP connectivity is not reliable, downstream treasury processes can be affected. IT needs to be engaged as a project partner from Day 1, not a downstream dependency.

Key actions

• Include IT in all project calls from kickoff. No exceptions.

• Define how data flows will shift from the legacy system to Kyriba. Document every interface.

• Align on integration approach (API, file-based, middleware) early.

• Bring treasury, IT, and end users into blueprinting sessions together, not sequentially.

• Establish clear ownership. Implementation partner, Client IT, and Client Treasury each own defined workstreams.

Which integrations need to be defined before build?

The key integration design areas are:

• ERP connectivity: GL posting, payment initiation, bank statement reconciliation

• Payment template standardization and format mapping across all paying banks

• Data exchange for investments, debt instruments, and FX deals

• Master data synchronization: counterparties, GL accounts, cost centers

Phase 5 — blueprinting & design considerations

What should TMS blueprinting cover? TMS blueprinting should define the data, taxonomies, integrations, payment templates, controls, governance, historical data, testing, cutover, and change management required for a successful go-live.

Blueprinting is where migrations are won or lost. Invest the time here. The 10 design areas below should each receive explicit attention before any configuration begins.

1. Referential data

Bank account master data, counterparty data, and entity structures need to be mapped from legacy to Kyriba's data model. Build a bank account attribute matrix early to capture all fields and their sources.

2. Taxonomies

Cash flow categories, deal taxonomies for debt and investments, and FX transaction types all need to be defined. Do not assume legacy taxonomy maps cleanly to Kyriba; it rarely does.

3. Integrations

Document every integration point: ERP, banking portals, data providers. Define interface specs before build begins.

4. Payment templates

Standardize payment template naming conventions and payment formats. Request all existing payment files and formats on Day 1 to avoid rebuilding from scratch.

5. Security and controls

Define the user access matrix, segregation of duties rules, and payment approval workflows. Migrations are the right moment to strengthen controls that may have eroded in the legacy system.

6. Governance

Assign a dedicated client point of contact accountable for all action items. Define a RACI across all workstreams. Migration projects involve circular dependencies; governance is what keeps them moving.

7. Historical data

Define the historical data migration strategy early: how far back, what format, what level of detail. Not all historical data needs to live in Kyriba; some data can remain accessible in the legacy system or archived separately.

8. Parallel testing

Build a test script library covering all Day 1 must-have workflows. Define explicit go/no-go criteria before cutover begins. Do not skip parallel testing to save time; it is the last line of defense.

9. Cutover planning

Design a phased wave plan where possible. Define hypercare support for the first 30–60 days post go-live. Identify who is accountable for each cutover step and what the rollback plan is.

10. Change management and user adoption

Often overlooked, change management is critical to post-go-live success. A well-configured platform can still underperform if users do not trust it, understand it, or know how to use it.

Key actions:

• Identify change champions within the treasury team early. These are the people who will influence their peers’ confidence in the new system.

• Involve end users in blueprinting, not just training. When people help design the system, they adopt it faster.

• Build a training plan that is role-specific, not generic. A payments clerk and a treasury analyst have different Day 1 needs.

• Communicate the go-live timeline internally and often. Surprises breed resistance.

• Plan for a hypercare period of 30–60 days where end users can ask questions and get fast answers without fear of judgment.

Phase 6 — execution principles

What practices keep a TMS migration on track? Keep a TMS migration on track by building and testing early, communicating consistently across teams, assigning clear ownership for dependencies, and improving the platform incrementally after go-live.

When the plan is in motion, these principles help maintain momentum and focus. They are simple to state and surprisingly hard to maintain under pressure.

Build and test early

Compressed timelines are recovered through early action, not shortcuts. Parallel testing should start at month three, not month five.

Communicate constantly

Misalignment between treasury, IT, and banking partners is the #1 source of delays. Weekly cross-functional touchpoints keep dependencies visible.

Own your dependencies

Every circular dependency needs a named owner. If no one owns it, it stalls. Dependencies without clear ownership are likely to cause delays.

Optimize incrementally

Know what "good enough for Day 1" looks like. Hypercare is for stabilization. Continuous improvement is for everything after.

What can treasury teams learn from TMS migration examples?

Every migration has its own shape. These five stories illustrate how the principles in this playbook apply across different legacy systems, business profiles, and risk environments when moving to Kyriba from a legacy treasury platform or related toolset.

Migrating from Reval and Treasura

$20B Global Steel Manufacturer

The challenge. This company was running two treasury systems simultaneously, a legacy Reval instance for derivatives and debt and a Treasura deployment for cash management, across a complex multi-entity, multi-currency global structure. Both contracts were expiring within the same window. The team needed to migrate everything, in one program, without disrupting daily treasury operations.

What made it hard. Dual-system source data meant two sets of taxonomies, two sets of bank connectivity requirements, and two sets of user workflows to rationalize. There was no clean "one-to-one" mapping into Kyriba. The blueprinting exercise was genuinely a design exercise.

The approach. Phased cutover by region, with bank connectivity and ERP integration workstreams running in parallel from month one. Cash management modules were stood up first, followed by debt and derivatives.

The outcome. Full migration completed on schedule. For the first time, the treasury team had a single, consolidated view of cash across all entities and geographies. Neither legacy system had been able to provide that visibility on its own.

Migrating from FIS Integrity

$14B Higher Education Institution

The challenge. A hard go-live deadline driven by a legacy contract expiration with no extension option. The team had approximately six months from kickoff to go-live, covering a treasury function that ran high payment volumes across a large number of bank accounts.

What made it hard. Time. Every week of delay was a week closer to a forced cutover. The team could not afford to let bank connectivity or ERP integration slip into the back half of the project.

The approach. All integration and bank connectivity work was initiated in week one of the project, running in parallel with blueprinting rather than waiting for it to complete. Parallel testing started at month three.

The outcome. Go-live achieved before legacy expiration. 15,000+ payments processed in the first six months with a 99.9% success rate. The treasury team entered hypercare with confidence rather than anxiety.

Migrating from Reval

$18B Insurance Company

The challenge. A heavily customized Reval implementation built up over many years to manage a complex investment and debt portfolio. The customizations had grown around Reval’s limitations, and many were workarounds that the team had started to treat as requirements.

What made it hard. Separating what the business genuinely needed from what had been built to compensate for a system’s shortcomings. The blueprinting sessions required real internal debate about which processes were worth keeping.

The approach. Blueprinting sessions were structured explicitly around the "replicate vs. redesign" question for every major workflow. The deal taxonomy was rebuilt from the ground up in Kyriba rather than mapped from Reval.

The outcome. Cleaner deal taxonomy, materially improved reporting, and a stronger audit trail: these outcomes would not have been possible with a lift-and-shift approach. The treasury team described the post-migration state as "the system we should have had for years."

Migrating from GTreasury

Global Ports and Logistics Operator

The challenge. A geographically dispersed treasury function managing cross-border payments across multiple currencies and banking relationships in multiple regions. Bank connectivity was the dominant risk: the company had a large number of banking partners, some in markets where Kyriba connectivity patterns were less established.

What made it hard. The sheer number of bank connectivity builds, compounded by regional variation in connectivity protocols. Payment templates had also grown organically over years and had never been standardized.

The approach. Bank connectivity workstream opened at project kickoff, not after blueprinting. Payment templates were rebuilt from source payment files, not from memory or documentation, to ensure accuracy. A named workstream owner was assigned to each banking relationship.

The outcome. All banking partners connected prior to go-live. Zero payment failures in the first 90 days. The payment template standardization exercise, though painful in the short term, eliminated a class of recurring operational errors that had persisted in GTreasury for years.

Moving from bank data aggregation tools

Mortgage and Home Lending Company

The challenge. A high-growth mortgage company that had been using bank data aggregation tools for cash visibility but had outgrown them. With payment volumes increasing and a lean IT team, they needed a real TMS without a heavy IT-dependent implementation.

What made it hard. The team had no TMS implementation experience internally, and IT bandwidth was genuinely constrained. The implementation needed to be designed around that reality, not despite it.

The approach. API-first integration approach, leveraging Kyriba's native bank connectivity and ERP connectors to minimize custom build requirements. The implementation was scoped to prioritize cash visibility and payment control on Day 1, with investment and FX modules planned for a later phase.

The outcome. Real-time cash position visibility achieved at go-live, a capability the company had never had before. IT involvement reduced materially post-implementation due to the API-native architecture. The phased scope approach meant the team went live with confidence on a well-tested core, rather than a stressed full-scope deployment.

What are the most common TMS migration pitfalls?

TMS migrations often encounter a predictable set of challenges. These six pitfalls appear frequently in troubled projects. Each can be addressed with a simple, disciplined approach.

Pitfall	Why it happens	How to avoid it
Bank connectivity delays	Started too late	Initiate at project kickoff, not after blueprinting
Scope creep	"Nice-to-haves" get treated as Day 1 requirements	Enforce the must-have/nice-to-have classification rigorously
IT disengagement	IT brought in too late, feels like an afterthought	IT in every call from Day 1
Legacy process replication	"Just copy what we have" mentality	Blueprinting asks: does this process work, or is it a workaround?
Testing shortcuts	Time pressure leads to compressed testing	Parallel testing starts at month three, not month five
User adoption failure	End users not involved until training week	Treasury end users in blueprinting; invest in change management

Is your organization ready for a TMS migration?

Use this checklist in early customer and partner conversations to assess whether the migration is ready to move from interest to execution.

Readiness Area	Questions to Confirm	Why It Matters
Business trigger	What is driving the migration? Renewal pressure, legacy support issues, spreadsheet reliance, ERP change, bank connectivity pain, controls, or growth?	Creates urgency and clarifies the business case.
Timeline	When does the legacy contract expire? What is the last safe decision point? Are there blackout periods such as year-end, audit, or major business cycles?	Defines the latest safe decision point and prevents a rushed cutover.
Scope	Which workflows are Day 1 must-haves? Which can wait until after go-live? Which existing processes should be redesigned rather than replicated?	Prevents scope creep and keeps the project focused on business-critical outcomes.
Current-state documentation	Are current workflows, bank accounts, payment formats, reports, integrations, users, and approval processes documented?	Determines how much discovery is needed before design and reduces the risk of missed requirements.
Bank connectivity	Which banks are in scope? Which already have Kyriba connectivity? Which require new setup? Who owns each bank workstream?	Identifies the longest lead-time workstream early and reduces cutover risk.
ERP and IT integration	Which ERPs and systems need to connect to Kyriba? What data needs to flow between systems? Is IT engaged from week one?	Confirms integration complexity, resource availability, and technical ownership.
Data readiness	Is bank account, entity, counterparty, GL, cost center, user, and security data complete and reliable?	Reduces mapping, configuration, testing, and cutover risk.
Controls	Are approval workflows, segregation of duties, user access, audit requirements, and payment controls clearly defined?	Turns the migration into a controls improvement opportunity, not just a system replacement.
Testing	Are test scripts, parallel testing scenarios, payment test cases, reporting checks, and go/no-go criteria defined?	Protects business continuity and builds confidence before go-live.
Change management	Are end users involved in design? Is role-based training planned? Are change champions identified? Is hypercare defined?	Reduces resistance, shadow spreadsheets, and post-go-live adoption issues.

What indicates that a TMS migration is ready to proceed?

A customer is likely ready to proceed when they have a clear migration trigger, an understood legacy timeline, executive sponsorship, IT engagement, named workstream owners, and agreement on what must be live on Day 1.

What indicates that a TMS migration is not ready?

A customer is not yet ready if the legacy deadline is unknown, bank connectivity has not been discussed, IT is not engaged, current workflows are undocumented, every requirement is treated as Day 1 critical, or end users are excluded until training.

What are the next steps in a TMS migration?

A TMS migration to Kyriba is not a small undertaking, but it is a manageable one when it is designed well. The organizations that migrate successfully share five things: they start early, understand the business trigger, invest in blueprinting, engage IT and banks from week one, and maintain clear accountability across all workstreams.

The goal is not just to migrate away from a legacy platform. It is to arrive at Kyriba with lower operational risk, better liquidity visibility, stronger controls, less manual effort, and a treasury function that is more capable than the one that left the legacy system.

What questions should you ask before starting a TMS migration?

A successful TMS migration starts with the right questions. Asking these five questions early helps the team create clarity, align stakeholders, reduce risk, and move toward go-live with confidence.

1. When does our legacy contract expire, and what is the "last drop" decision point?

2. Which of our banks already have Kyriba connectivity, and which require a new build?

3. Which workflows are must-have on Day 1, and which are legacy workarounds we should redesign?

4. Who owns each workstream, and is IT engaged from week one?

5. What does "good enough for go-live" look like, and what can wait for post-implementation?