DIGITAL TRANSFORMATION / MODERNISATION
PROPELOO engineers digital transformation programmes — from legacy system assessment and transformation roadmap through strangler fig migration, API-first re-platforming and the change management that determines whether the technology actually changes how the business operates. Digital transformation is not a technology project. It is a business change project that requires technology.
The history of large-scale IT transformation is littered with multi-year, nine-figure projects that were cancelled, delivered years late, or delivered on time and never adopted. The common failure pattern: a "big bang" replacement where all functionality is rebuilt in the new system before the old one is switched off. Every month the old system must continue running is a month of parallel maintenance. Every delay extends this period. By the time the new system is ready, the business has changed and the requirements have shifted. PROPELOO uses the strangler fig pattern for every digital transformation engagement: new capabilities are built in the modern system while the legacy system continues to run, traffic is migrated incrementally, and the legacy system is decommissioned service by service — never all at once.
Technical debt quantification (SQALE model or custom), dependency mapping, business capability mapping, transformation cost/benefit analysis and prioritisation framework for which components to transform first.
Route new features to modern system while legacy continues serving existing functionality. Gradual traffic migration by feature, user segment or data category. Legacy system decommissioned incrementally as its responsibilities transfer.
Anti-corruption layer API in front of legacy system, new modern UI consuming the API, gradual backend replacement behind the API boundary. UI modernisation without business logic rewrite risk.
Legacy database to cloud-managed database migration, schema modernisation, data quality remediation, event streaming setup for real-time data access and data warehouse for analytics separation.
Containerisation of extracted services, Kubernetes deployment, managed cloud services replacing on-premises infrastructure, CI/CD pipeline and infrastructure as code.
Event-driven integration between legacy and modern systems, message bus for decoupled communication, legacy system adapter patterns and API gateway for unified access layer.
The technology is rarely the hard part of digital transformation. The hard part is changing how the organisation thinks about its own processes while keeping the lights on.
The strangler fig pattern deploys new functionality alongside legacy systems — traffic migrates gradually as confidence builds, and the legacy system is strangled incrementally as its responsibilities are taken over. A big-bang replacement requires building 100% of functionality before the switch is flipped. Strangler fig delivers value at 20% and continues delivering as each domain migrates.
Axiom:
Digital transformation fails when it is technology-led ("we will re-platform the monolith as microservices") rather than business-led ("we need to reduce our quote-to-cash cycle from 14 days to 2 days"). Map business capabilities first. Identify which capabilities are competitive differentiators (build), which are commodity functions (buy or SaaS), and which are actively harming the business (transform urgently).
Axiom:
Not all legacy code needs to be replaced. Code that is stable, well-tested and does not need to change is not technical debt — it is running infrastructure. Replacement is justified when: the code prevents adding new business capabilities, the maintenance cost exceeds rewrite cost, or the security risk of the existing system creates unacceptable risk.
Axiom:
A technically excellent new system that is not used is not a transformation — it is a failed technology project. Digital transformation requires: user involvement in the design process, adequate training, a parallel period where both systems are available, feedback loops to address adoption barriers and executive sponsorship for the mandatory transition.
Axiom:
Impact: Strangler fig for any system where downtime is not acceptable or where the full scope of the transformation exceeds 6 months of development.
Impact: Combination: start with a low-complexity component to demonstrate the process works, then move to high-value capabilities. Avoid starting with the most complex/critical components.
Impact: Modular monolith is usually the correct target for legacy monolith transformation — cleaner than the current state, without the operational overhead of microservices.
Impact: Migrate to managed cloud database first (lower risk), then modernise schema incrementally via expand-contract migrations.
Impact: Anti-corruption layer (ACL) is the standard pattern — new systems interact with the clean ACL API, the ACL translates to legacy system protocols. Legacy complexity stays contained.
Impact: Gradual cohort migration for large user bases. Feature-gated for systems where specific new capabilities drive adoption motivation.
Strangler fig migration from legacy monolith to modular cloud-native architecture — incremental extraction, API-first boundaries, no big-bang cutover.
Data centre exit with simultaneous modernisation — containerisation, managed services adoption and cloud-native architecture.
Legacy ERP or CRM replacement with modern custom or SaaS platform — data migration, integration layer, user training and phased cutover.
Digitise manual business processes — workflow automation, digital forms, approval workflows and integration with existing systems.
Add API layer in front of legacy system, build modern UI consuming the API, gradually replace backend functionality behind the API.
Legacy data warehouse to modern data platform — Snowflake/BigQuery migration, dbt transformation layer, self-service analytics.
Stack: Node.js / Go / Java Spring Boot, PostgreSQL (managed), Redis, Kafka (event streaming), REST / GraphQL APIs
Stack: AWS / GCP / Azure, Terraform, Kubernetes / ECS, ArgoCD (GitOps), CI/CD pipeline
Stack: Apache Kafka, AWS EventBridge, MuleSoft / Boomi, Custom adapters, API Gateway
Stack: AWS DMS, dbt (transformations), Apache Airflow, Debezium (CDC), Data validation scripts
Stack: Anti-corruption layer patterns, SOAP-to-REST adapters, Legacy database connectors, File-based integration (SFTP, EDI)
Stack: Datadog, Prometheus + Grafana, Custom migration progress dashboards, Business metric tracking
Legacy systems often have accumulated security debt — default passwords, unencrypted databases, overly permissive access. The transformation is an opportunity to address this debt, not carry it forward.
During parallel running, both systems have access to production data. Both must have equivalent security controls. A vulnerability in the legacy system during transformation is still a vulnerability.
Data in motion during migration is a target. Encrypted transfer, minimal exposure window, checksums for integrity and access logs for all migration operations.
Legacy systems often have coarse-grained access control. The new system is an opportunity to implement proper RBAC with the principle of least privilege.
Every new API boundary introduced during transformation is a new attack surface. Authentication, authorisation, input validation and rate limiting must be implemented for every API, not added later.
Compliance audit trails must be continuous during transformation. Log entries from both legacy and new system must be correlated so the complete history of any transaction is available.
Legacy system audit, business capability mapping, technical debt quantification, transformation roadmap with milestones.
Modern architecture design, API boundaries, data migration strategy, integration patterns.
Modern infrastructure, CI/CD, monitoring, API gateway and anti-corruption layer.
Extract lowest-risk domain to modern system, validate, run parallel, migrate traffic.
Domain by domain extraction per roadmap — each follows: build, test, parallel run, migrate, decommission.
Progressively decommission legacy components as modern equivalents are proven in production.
Performance tuning, cost optimisation, documentation and capability hand-off.
There is no single answer — it depends entirely on scope. A specific legacy application with a defined boundary: 3-9 months. A full enterprise platform transformation: 2-5 years. The strangler fig approach means value is delivered continuously throughout rather than at the end. We recommend planning transformation in 6-month phases with defined outcomes per phase rather than a single multi-year programme.
Named after a vine that grows around a host tree, gradually taking over until the host dies. In software: a new system is built alongside the legacy system. New features go into the modern system. Existing features are migrated domain by domain. A proxy/router directs traffic to either system. As each domain migrates, the legacy system handles less traffic. Eventually the legacy system handles nothing and is decommissioned. This avoids the big-bang cutover risk entirely.
Quantify the cost of not transforming: maintenance cost per year (developer hours on legacy, third-party support costs), opportunity cost (features that cannot be built on the legacy platform), risk cost (security vulnerabilities, vendor end-of-life). Compare against transformation cost and expected benefits (reduced time-to-feature, lower maintenance cost, new capability). Most transformation business cases are justified by the maintenance cost reduction alone over a 5-year horizon.
Technical debt is the future cost of shortcuts taken in current code. SQALE (Software Quality Assessment based on Lifecycle Expectations) provides a quantitative model: each code quality issue has a remediation cost estimate; total technical debt is the sum across the codebase. SonarQube implements SQALE. The ratio of remediation cost to estimated development time (the "debt ratio") indicates the severity. 5% debt ratio: manageable. 50%: concerning. 100%+: transformation required.