Strangler-fig migration
Extract bounded contexts one at a time, cut over gradually behind a routing layer, and keep rollback available at every step. The legacy system stays live throughout the programme.
Services
Legacy Software Modernization Services for US & EU Companies
Modernise legacy applications without the rip-and-replace risk. YuSMP Group migrates business-critical systems through the strangler-fig pattern — incremental microservice extraction, framework upgrades, and cloud migration that keep production running throughout. Typical wins: COBOL and Delphi to Java or .NET, PHP to Node, monoliths to microservices, on-prem to AWS, Azure, or GCP, and .NET Framework to .NET 8. Compliance is baked in: GDPR-aligned, ISO 27001 ready, SOC 2 Type II in progress, HIPAA-capable.
Most modernisation projects fail when teams attempt full rewrites — scope balloons, the roadmap freezes, and the business loses patience long before the new system is ready. We default to strangler-fig refactoring instead: extracting bounded contexts into microservices, then migrating capabilities one by one behind a routing layer. The legacy system stays in production the whole way through. Our approach is architecture-first: a read-only discovery phase maps the existing system and its dependencies, a migration plan quantifies risk and sequences phases, and incremental cutover includes rollback at every step. Reference modernisations span manufacturing (REHAU), industrial systems (CheckList), and operational platforms (xRouten).
Modernization paths we deliver
Framework upgrades
.NET Framework 4.x to .NET 8, Java 8 to Java 21 on Spring Boot, PHP 5/7 to PHP 8, AngularJS and Knockout to React or Vue. In-place upgrades when ROI beats refactoring.
Monolith → microservices
Only where ROI justifies it. We will tell you when a tidy modular monolith is the better answer — microservices add operational cost and only pay back at real scale.
Cloud migration
Lift-and-shift, replatform, or refactor on AWS, Azure, or GCP. We pick the right pattern per workload — not a one-size-fits-all blanket migration that wastes the cloud bill.
Database modernisation
Oracle to PostgreSQL, on-prem SQL Server to managed Azure SQL or RDS, mainframe DB2 to cloud-native stores. Change data capture, dual-run, and reconciliation built in.
Frontend modernisation
jQuery, Knockout, and AngularJS to React, Vue, or Next.js. Design system extraction, micro-frontend boundaries, and SSR where it earns its keep on Core Web Vitals.
Modernization stack
.NET 8
C#
Java 21
Spring Boot
Node.js
TypeScript
Python
Go
PostgreSQL
MongoDB
Kafka
Kubernetes
AWS
Azure
GCP
Terraform
Strangler Fig
Domain-Driven Design
OpenTelemetry
Datadog
GitHub Actions
Argo CD
How we modernise legacy systems
-
01
Read-only discovery
Architecture mapping, dependency graph, hot-path tracing, and risk scoring across modules and data flows. No code changes — we only read, profile, and document the system as it actually runs.
-
02
Plan
A strangler-fig roadmap with quantified migration phases, dependency sequencing, rollback strategy, and budget envelopes per phase. You approve the plan before a single line of new code is written.
-
03
Migrate
Incremental cutover by bounded context with weekly demos, dual-run validation, and reconciliation jobs. Each phase ships a real capability to production behind feature flags, not a slideware milestone.
-
04
Stabilise
SRE practices, observability with OpenTelemetry and Datadog, error-budget policies, and orderly deprecation of legacy paths once the new system has proven itself in production for at least one quarter.
Engagement models
Fixed-Price Discovery + Plan
4–6 weeks. Architecture audit, dependency graph, risk scoring, and a phased modernisation plan with quantified budgets. Deliverable you can take to any vendor — not just us.
Time & Materials Migration
Default model for the migration itself. Monthly invoicing per role and seniority, full visibility on hours and capacity, scope flexes as bounded contexts reveal their true shape.
Dedicated Modernisation Squad
For long-running multi-year programmes. A persistent squad — backend, frontend, DBA, DevOps, delivery lead — owns the modernisation roadmap alongside your in-house engineers.
Selected work
Logistics · Last-mile · Mobile
xRouten
Android + iOS refactor and rebuild for a German last-mile logistics operator — multi-point route planning, real-time driver tracking and in-app invoicing live in the EU.
Industrial · Manufacturing
CheckList
Offline-first ecosystem replacing paper journals for reactor process control — Android, admin, controller dashboard.
Manufacturing · E-commerce
REHAU
B2B e-commerce and product configurator for a global polymer manufacturer with multi-region pricing, stock and dealer workflows.
Why US & EU operators pick YuSMP for modernization
GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · PCI DSS scope-ready · CCPA-acknowledged
Strangler over rewrite
We do not pitch big-bang rewrites. The default is incremental strangler-fig migration with the legacy system live throughout — lower risk, faster ROI, no roadmap freeze.
Quantified risk before kickoff
Discovery deliverable includes a risk register, dependency graph, and phase-level budget envelopes. You approve the plan with numbers, not vibes, before migration starts.
Compliance-aware
GDPR, SOC 2, HIPAA, and PCI DSS scope considered from day one. EU data residency, US options on request, audit-ready logs, encrypted endpoints, and DPAs available.
For payments, lending, and healthcare modernisations we work inside your existing compliance scope — PCI DSS QSA, HIPAA Business Associate, or HITRUST — without disrupting certification.
Frequently asked questions
Should we rewrite or modernise our legacy app?
In most cases, modernise. Full rewrites fail at a rate well above 50% because they freeze the roadmap, multiply scope, and force a single high-risk cutover. We default to the strangler-fig pattern: keep the legacy system running, route new traffic to extracted microservices one bounded context at a time, and retire legacy code only after the new path is proven in production. A rewrite is justified only when the legacy stack is unmaintainable, no engineers remain, or compliance forces it — and even then we phase it.
What does strangler-fig migration actually mean?
Strangler-fig is an incremental refactoring pattern: a routing layer sits in front of the legacy system and gradually redirects requests for specific capabilities to new microservices. The legacy code keeps running for everything not yet migrated. Each bounded context — orders, billing, identity — is extracted, deployed, dual-run for validation, then cut over. Rollback is a routing change, not a redeploy. Over months the new system “strangles” the old one until the legacy app can be safely deprecated.
How long does typical modernisation take?
Discovery and migration plan run 4–6 weeks. The migration itself depends on system size and risk appetite: a mid-size .NET Framework or PHP monolith with 200–400 KLOC typically lands in 9–18 months of incremental cutover. Mainframe and COBOL programmes run multi-year by design. We work in 2–3 month phases with a demoable cutover at the end of each phase, so business value lands continuously instead of waiting for a big-bang release.
Can you modernise without taking the system offline?
Yes, that is the point of strangler-fig. The legacy system stays in production throughout. Traffic shifts behind a routing layer (API gateway, reverse proxy, or feature flag) as each bounded context comes online. We dual-run the old and new paths, compare outputs, and only flip the canonical write once parity is confirmed. Maintenance windows are limited to database cutovers and are usually under one hour, scheduled with your operations team.
Do you support specific legacy stacks (COBOL, Delphi, .NET Framework, Oracle Forms)?
Yes. We have shipped modernisations across .NET Framework 4.x to .NET 8, Java 8 to Java 21 on Spring Boot, PHP 5/7 to PHP 8 and Node.js, Delphi/Pascal to C# and TypeScript, Oracle Forms and PL/SQL to PostgreSQL with Node or Java services, classic ASP and VB6 to modern web stacks, and AngularJS/Knockout/jQuery to React, Vue, or Next.js. COBOL and mainframe workloads are handled in partnership with specialist re-hosting vendors when needed.
How do you handle data migration and dual-run periods?
Data is the highest-risk part of any modernisation, so we treat it as a first-class workstream. We start with change data capture (Debezium, native log shipping, or vendor CDC) to keep new and old stores in sync. During dual-run, writes go to both systems and a reconciliation job flags divergence inside one hour. We freeze the legacy write path only after a parity window — typically 2–4 weeks — and keep the legacy database as a read-only fallback for 90 days after cutover.