01 · Business-process boundary map
BluePi used business processes and code dependencies to identify areas that could move without a complete rewrite.
Customer work · Healthcare technology
A pharmacy benefits application moved from a decades-old monolith to service boundaries
A pharmacy benefits provider depended on a decades-old application whose interdependent code had become difficult to maintain and scale. BluePi used a strangler-pattern transition and refactored selected application areas into cloud-native service boundaries.
Incremental modernization for a pharmacy benefits monolith
A pharmacy benefits provider depended on a decades-old monolithic application with interdependent code that was difficult to maintain, update, and scale. BluePi used a strangler-pattern transition to refactor selected areas while the remaining monolith continued to run.
02 · Coexisting service boundaries
Selected application areas were refactored toward cloud-native service boundaries while current operations stayed on the remaining monolith.
03 · Smaller maintenance surface
Each moved boundary made individual processes easier to manage and update, improved the path to scale, lowered maintenance cost, and improved system performance.
From dependency mapping to strangler-pattern extraction
BluePi mapped one process boundary, checked the dependencies that had to remain compatible, refactored selected application areas, and let new service boundaries coexist with the remaining application.
Map the monolith boundary
Business processes and code dependencies established which areas could move without a complete rewrite.
Extract selected processes
The strangler pattern allowed refactored services to coexist with the remaining application.
Reduce the monolith incrementally
Each moved boundary created a smaller surface for later maintenance and modernization work.
Where this pattern fits
This case is relevant when a long-running application is difficult to maintain and scale, but replacing every business process in one release would create excessive delivery risk.
Working-session promptsQuestions that define the delivery boundary
Use these prompts to decide whether the case fits your operating problem and what a first deployment should prove.
- Which business process can move independently from the monolith?
- What dependencies and behavior must remain compatible during coexistence?
- Where should routing distinguish the extracted service from the existing path?
- How will teams validate that the refactored process preserves required behavior?
- Which maintenance, release, scaling, or performance measure should improve first?
A practical first step
A first engagement can map one business-process boundary, identify its dependencies, refactor a representative slice, route that slice through the strangler boundary, and validate coexistence with the remaining monolith.
Case details
Open a section to review the customer problem, implementation, business change, and architecture.
01Starting point
The existing monolith carried tightly coupled business processes. Changes in one area could affect others, maintenance was slow, and the application could not scale efficiently as business demand grew.
02What BluePi did
BluePi mapped application boundaries, identified areas that could move independently, and applied a strangler pattern around the existing system. Selected functions were refactored and moved toward cloud-native microservices while the remaining monolith continued to support existing operations.
- Business-process and dependency mapping
- Strangler boundary around the existing application
- Selected application-area refactoring
- Cloud-native service-boundary design
- Staged coexistence with the remaining monolith
03What changed
The modernization created smaller application boundaries that teams could manage, update, and scale with less dependence on a coordinated monolith release.
- Individual business processes became easier to manage and update
- Service boundaries supported more independent departmental work
- The application gained a clearer path to scale
- Maintenance cost decreased
- System performance improved