How Twenty20 Systems Migrated Memorial Sloan Kettering's IBM DataPower Estate to Workato in 5 Weeks

Memorial Sloan Kettering Cancer Center (MSK) is the world's oldest and largest private cancer center — a 130-year-old institution whose clinical, research, and operational systems span an enterprise as complex as any in healthcare. Behind the care delivery is a dense integration estate connecting hundreds of applications, partner systems, and internal services that cannot afford downtime.

That estate had a problem. MSK needed to retire its IBM DataPower API gateway and migrate over 150 integrations to a cloud-native platform — without disrupting a single clinical, research, or enterprise system in production. Working as the primary delivery partner alongside Workato's professional services team, Twenty20 Systems executed the bulk of the migration using a structured pattern of proxy collections, recipe collections, and custom connectors. The engagement closed in five weeks.

What Was the Ask

MSK had built a substantial portion of its integration estate on IBM DataPower — a long-standing API gateway and security appliance. Over the years, that estate had grown into hundreds of proxy APIs and transformation flows connecting enterprise applications, internal services, and partner systems.

DataPower had served its purpose. But the platform was aging, expensive to operate, and increasingly difficult to evolve at the pace MSK needed. The decision was made to migrate the entire integration estate to a modern, cloud-native iPaaS — one the MSK engineering team could own and extend going forward.

Twenty20 was brought in to execute the migration within a five-week window as part of the broader Workato professional services delivery.

In one line: MSK needed to replace its IBM DataPower API gateway with a modern integration layer at speed — and we delivered the bulk of that migration as proxy collections, recipe collections, and custom connectors on Workato.

Why Legacy API Gateway Replacement Was Necessary

For healthcare organizations, the cost of standing still on legacy integration infrastructure is rarely visible — until it is. DataPower's limitations had become a structural constraint on MSK's ability to evolve:

• Operational cost: The platform required specialized skills to operate and maintain, creating dependency risk as internal expertise became harder to retain.
• Velocity bottleneck: Adding new integrations or modifying existing ones required disproportionate effort, slowing down the engineering teams that depended on them.
• Cloud-native readiness gap: As MSK's application landscape shifted toward SaaS and cloud-hosted systems, DataPower's architecture became increasingly mismatched with the integration patterns those systems required.
• Scalability ceiling: The estate had grown organically. Without refactoring, each new integration compounded the complexity and fragility of what was already there.
• Broader Connector Ecosystem: Hundreds of prebuilt connectors for Salesforce, Workday, ServiceNow, SAP, Slack, etc.

The trigger was clear: decommission DataPower, migrate the integration estate, and put MSK in a position to extend and own its integration layer without external dependency.

How We Went About It

The Gateway Replacement Pattern

We didn't treat this as a line-by-line rewrite. The core design constraint was backward compatibility: consumer applications had to experience no functional change. Same endpoints, same payloads, same security posture — with the backend operating entirely on the new platform.

To achieve this, we used a gateway replacement pattern built on three Workato constructs:

• Proxy Collections — for pass-through flows where no transformation was needed
• Recipe Collections — for transformation, orchestration, and any flow requiring conditional logic
• Custom Connectors — for centralized authentication and reusable request-shaping logic

Why Custom Connectors Over Standard HTTP Connector

We chose to build custom connectors rather than use Workato's standard HTTP connector for two reasons. First, they allowed us to centralize authentication logic — eliminating duplication across recipes and ensuring consistent behavior wherever a given upstream system was called. Second, they gave us a single place to maintain and update request-handling logic as the platform evolved.

The operational upside is meaningful: when something needs to change, there is one place to change it.

Systems Migrated

The scope of the engagement covered the major pillars of MSK's enterprise application landscape, plus a long tail of internal and partner systems:

• Workday — HR, payroll, and finance integrations supporting the employee lifecycle and downstream financial flows
• Twilio — patient and staff communications, including SMS and notification workflows that had to remain reliable through the cutover
• Internal services and partner APIs — systems including Remote Monitoring, Thea-Services, Ping, and others, each with its own contract, payload shape, and security model

Authentication Patterns Supported

If there was one dimension of the migration that pulled us in multiple directions simultaneously, it was authentication. The estate spanned several distinct auth models, and the integration layer had to handle all of them:

• OAuth 2.0 — the most common pattern across SaaS upstreams, with the standard access-token and refresh-token lifecycle
• API key / auth key — used by internal and partner systems where simpler header-based auth was the standing pattern
• JWT-based auth — signed-token flows where the token had to be minted, refreshed, and presented on every downstream call. We used an out-of-the-box JWT connector to generate tokens using RS256 as the security algorithm, with custom claims configured per upstream

For OAuth and JWT systems, token refresh handling was the risk point. Rather than modeling refresh logic inside individual recipes — where it would have been duplicated and inconsistent — we encapsulated the full token lifecycle inside each upstream's custom connector: detect expiry, execute the refresh flow, persist the new token, and retry the in-flight call transparently. Recipes never see the refresh. They call the connector, and the connector returns a valid response.

API versioning was also a design requirement: multiple versions of the same API were hosted in parallel, allowing different consumers to migrate independently without requiring coordinated upgrades or disrupting existing integrations.

Challenges and What We Did About Them

A migration of this density, on a platform still being adopted across the organization, surfaced constraints that shaped the design. None became blockers — but they are the kind of trade-offs every real enterprise migration runs into.

Timeout headroom. Several upstream systems didn't respond within the platform's default API timeout — particularly endpoints that aggregated data or hit cold caches. We raised timeout limits where it was safe to do so, keeping longer-running calls within their real-world response envelope rather than failing on artificially tight ceilings.

OIDC gaps. The platform's OIDC support had gaps that affected a subset of our upstream patterns. Rather than wait for a platform-level resolution, we designed targeted workarounds using the platform's own APIs to fetch client details and keep the migration on schedule.

Unauthenticated legacy endpoints. Some legacy consumers depended on endpoints that carried no authentication. The platform doesn't expose this as a native pattern. We found alternative paths to keep those flows functional through the cutover while working with MSK's stakeholders on the longer-term security posture for those endpoints.

What Were the Learnings

Two things from this engagement that we carry into every subsequent one:

Proxy Collections are powerful — until they aren't. Workato Proxy is an elegant feature on the consumer side. The same simplicity that makes it easy to adopt also defines its ceiling. When a flow requires conditional logic, transformation, or behavior that doesn't fit the proxy model cleanly, the right answer is to move up to an API Recipe. You trade a small amount of setup time for significant flexibility.

Build custom connectors early when the same auth or request-shaping logic appears more than twice. The build cost pays back by the third reuse. More importantly, the operational benefit — one place to fix, one place to update — compounds over the life of the integration estate. This is the difference between a maintainable platform and a distributed accumulation of duplicated logic.

Conclusion

The MSK engagement is a representative example of what enterprise API gateway migration looks like in practice: it is less about replacing one box with another, and more about choosing the right building blocks on a modern platform so the next change is easier than the last.

The proxy + recipe collection + custom connector model we deployed isn't specific to MSK. It's a reusable pattern — one the MSK team can keep extending as additional systems come online.

We're proud of how the joint team executed on a compressed timeline, and we're looking forward to seeing the pattern scale across the rest of the estate.

Considering a legacy API gateway migration or integration modernization project? Whether you're on DataPower, MuleSoft, or a homegrown integration layer, the architectural decisions made at the start determine how maintainable and extensible the result will be.