Customer and commercial details have been generalised.
Context
A digital subscription business relied on a Salesforce integration for customer, user, entitlement and webhook processing. Years of change had spread the runtime across Flows, invocable actions, asynchronous jobs, handlers and legacy branches.
The constraint
The live capabilities could not disappear during redesign, but code-for-code parity would simply reproduce the support problem. The replacement needed to preserve what operators and customers relied on while reducing the number of places an engineer had to inspect when something failed.
Delivery design
EKWIS defined one integration path: typed Apex services for authentication, signing, transport and external API handling; Flow and Lightning components for Salesforce orchestration and operator actions; and thin webhook handlers that pass work into the supported processing layer. Useful mapping and audit records remained, while fields and automations tied only to retired routes could be removed.
How risk was controlled
- A capability matrix defined parity in business terms rather than by copying old code.
- Authentication, transport, orchestration and user-facing outcomes had clear ownership boundaries.
- The replacement was validated in non-production against an external sandbox before live cutover.
- Any coexistence of old and new logic was limited to deployment and cutover.
- Operational audit and repair actions were designed as supported features, not hidden workarounds.
Acceptance definition
The replacement had to retain the agreed live endpoints and business capabilities, improve error visibility and day-to-day support, remove obsolete runtime residue and leave one production architecture for future change.