01
Mainframe-attached workloads
COBOL / DB2 / VSAM / CICS-attached green-screen UIs and batch programs replatformed onto modern stacks with parity-tested cutover. Phased per workload, never big-bang.
Custom Software · FORGE
Legacy Modernization.
Strangler-fig migrations off mainframe, in-house Java, .NET monoliths, and Lotus Notes. Phased rollouts with documented rollback per workload, not the big-bang cutover that everyone has been warned about and somehow still ships.
- Practice
- Custom Software
- Department
- FORGE
The problem
Most legacy modernization fails because the cutover plan was the proposal, not the engineering plan.
The pattern across legacy programs: a Big-4 deck with a 24-month roadmap, a parallel-run window that nobody planned for the third quarter when volume doubles, a rollback plan that exists in slideware but has never been tested, a target architecture optimized for the modernization vendor’s preferred stack rather than the operational reality of the customer. Then production cuts over on a Saturday and reconciliation breaks on Monday morning.
Prosigns runs legacy modernization as a strangler-fig discipline. Every workload migrates with documented rollback, behind a feature flag, alongside the legacy until reconciliation passes for two billing cycles. Architecture decisions are made against the actual integration surface and operating profile, not against the vendor’s reference architecture. The bench in the proposal is the bench at cutover. We stay through the first audit cycle.
Where it ships
5 use cases, in production.
Specific applications we’ve built and operated. Not speculative: every example below is grounded in a real shipped engagement.
- 02
12–18mo
typical program duration
In-house Java monoliths
10–20-year-old Java EE / Spring monoliths decomposed via strangler-fig: extract bounded contexts, stand up modern services alongside, route traffic gradually until the monolith is shut off.
- 03
.NET Framework → .NET (modern)
.NET Framework 4.x apps modernized to .NET 8/9, including WCF replacement, EF6→EF Core migration, and IIS-on-Windows-Server → containerized cloud-native deploys.
- 04
Lotus Notes / Domino apps
Hundreds of Notes databases catalogued, prioritized, and either migrated, retired, or replaced with custom apps. Honest about which apps are worth modernizing and which should just go away.
- 05
Custom client/server apps
PowerBuilder, Delphi, VB6, Access, apps that have outlived their original engineers. Documented per-app what to replatform, what to rearchitect, what to retire.
How we engage
4 phases, named in the SOW.
Each phase has a deliverable, an owner, and an acceptance criterion. Not slogans, operating rules.
- 01
Inventory + per-workload classification
Every workload classified: replatform (lift onto modern infra), rearchitect (rewrite), retain (still fits), or retire (kill it). Decisions are written down with the rationale, not made in a steering meeting six months later.
- 02
Strangler-fig topology
Modern services stand up alongside the legacy. Traffic shifts gradually, behind feature flags, under reconciliation. The legacy stays live and authoritative until reconciliation passes for the agreed window, typically two billing or month-end cycles.
- 03
Rollback per workload
Every cutover has a documented rollback that's been tested against a real failure mode, not a paragraph in the migration plan. If reconciliation drifts, we revert the workload while the rest of the program continues.
- 04
Operate through the first audit cycle
Modernization programs aren't done at cutover; they're done after the first SOC 2 / regulatory / financial-close cycle proves the new stack survives examination. We stay until that’s on the wall.
Capabilities
What’s in scope.
- Mainframe modernization (COBOL, DB2, VSAM, CICS-attached)
- Java monolith decomposition (Spring, Java EE, JBoss, WebLogic)
- .NET Framework → .NET (modern), WCF replacement, EF migration
- Lotus Notes / Domino app cataloguing + replatform / retire decisions
- Client/server app modernization (PowerBuilder, Delphi, VB6, Access)
- Strangler-fig with feature flags + reconciliation harnesses
- Documented rollback per workload, tested against real failure modes
- Cutover support through the first audit / regulatory cycle
Stack
Tools we use in production.
- Modern target stack
- TypeScript / Next.jsJava / Spring BootC# / .NET 8+Python / FastAPIGo
- Mainframe bridges
- IBM z/OS ConnectMicro Focus EnterpriseHeirloomAWS Mainframe Modernization
- Integration
- Apache KafkaRabbitMQAWS EventBridgeAzure Service BusMuleSoftApigee
- Databases
- PostgreSQLSQL ServerOracleDB2 (legacy)VSAM (legacy)MongoDB
- Cloud + infra
- AWSAzureGCPKubernetesTerraformAnsible
- Reconciliation + ops
- DatadogSplunkCustom recon harnessesFeature flags (LaunchDarkly, Unleash)
Selected work
Quantified outcomes, not adjectives.
Common questions
Asked before the first call.
- 01
Replatform, rearchitect, or retire, how do you decide?
Per workload, against three signals: business value (does it still earn its keep?), modernization fit (does the workload model port cleanly to a modern stack?), and operational cost (what does it cost to keep it running on the legacy?). We write the recommendation down with the rationale. If the workload doesn't earn its keep, we recommend retire, even if that's awkward for the program scope.
- 02
How long does legacy modernization take?
Programs land in 12–24 months for the workloads that matter. Anything claiming 6 months for a 20-year-old monolith is selling proposal-ware. Anything claiming 36+ months is hiding a re-architecture cost in a modernization budget. We're honest about the timeline and the dependencies.
- 03
Do you do big-bang cutovers?
No. Big-bang cutovers fail more often than they succeed and the failure modes are catastrophic. Every workload gets phased, feature-flagged, and reconciled. If your program has been scoped as a big-bang, we'll show you why phased is faster, cheaper, and lower-risk before we sign a statement of work.
- 04
What about the data?
Dual-write windows during cutover, reconciliation harnesses comparing legacy vs. modern outputs row-by-row, and a documented rollback per data domain. We never decommission the legacy data store until reconciliation has passed for the agreed window, typically two month-end / billing cycles.
- 05
Who owns the modernization after cutover?
Choose: stay with us under Managed Services for ongoing operations, or hand off with a 90-day shadowing period, full operational documentation, and an explicit handoff to your team or a successor vendor. We don't make the handoff a renewal-trap.
- 06
What does a legacy modernization program cost?
Inventory + classification + ADR set: 6–10 weeks, $150K–$400K. Per-workload modernization: $500K–$3M depending on complexity. Programs with 5–10 critical workloads typically run $2M–$8M total. Mainframe replatforms run higher. Managed Services through the first audit cycle: $50K–$300K monthly retainer.
Within Custom Software
Other capabilities in this practice.
Talk to us
Bring a legacy modernization problem. We’ll bring a senior engineer.
A senior engineer plus the FORGE department lead joins the first call. No discovery gauntlet, no junior reps.