Modernization is a sorting problem

A ten-year-old IBM Sterling B2B Integrator environment contains three categories of work: processes that still serve the business and run reliably, processes that serve the business but are fragile or undocumented, and processes that serve nothing at all. Modernization programmes fail when they treat all three the same way, either by rebuilding everything at enormous cost or by migrating everything and carrying the problems forward.

The useful first step is not technology selection. It is classification.

What to keep, fix, or retire

Sort every integration into one of three outcomes before planning any work.

Keep as-is

Runs reliably, is understood, and meets current partner and security requirements. Carry it forward unchanged. ITX maps and XSLTs that still process correctly belong here far more often than modernization proposals assume.

Refactor

Serves a real purpose but is fragile: hard-coded paths and credentials, no error handling, partner-specific logic that should be configuration. These are the candidates for reusable patterns.

Retire

No traffic in twelve months, or a partner relationship that ended. Verify with data rather than opinion, then remove it before it consumes another test cycle.

Use traffic data, not interviews

Ask a team which integrations matter and you will get the ones they remember. Query the platform instead: distinct business processes executed over the last twelve months, volumes per partner, last execution time per flow. The result is routinely uncomfortable, with a substantial share of configured flows showing no activity at all.

This exercise also tends to reveal duplicate processes: five variants of the same pattern, cloned for five partners, that diverged as each was patched independently. Those five become one parameterized process plus five configuration records, and that single change removes most of the future maintenance cost.

Replace the pattern, not the platform

The common complaint about IBM Sterling B2B Integrator is that onboarding is slow and operations are opaque. Neither is inherent to the engine. Both come from the practice of building a custom business process per partner, which makes every change a development task and every question a console investigation.

Two changes address most of it without replacing anything. First, move to parameterized processes driven by configuration, so new partners reuse a tested pattern. Second, give operations a way to see file activity without console access, which is what the DIVE platform does while leaving the execution engine untouched.

A sequence that keeps risk low

  • Inventory and classify, using traffic data as the evidence
  • Retire dead flows first — the cheapest work with the most immediate benefit
  • Standardize on parameterized patterns for the most common protocol and routing combinations
  • Migrate new partners onto the pattern before touching existing ones
  • Convert existing partners opportunistically, when a change is needed for another reason
  • Address infrastructure separately from integration logic, so upgrades and refactoring do not share a change window

What modernization does not mean

It does not require abandoning working ITX maps, rewriting XSLTs that produce correct output, or re-onboarding a partner community that is functioning. Each of those carries partner-facing risk with no operational return. Keep them, document them, and spend the budget on the parts that actually cost you time.

For delivery of this work, see IBM Sterling B2B Integrator Ecosystem Services.