Application Modernisation Methodology: Transform Once, Scale Forever

You cannot apply the 6Rs to a system you haven't mapped. Phase one is unglamorous: catalogue every integration, every cron job, every spreadsheet that quietly became part of the system, and the actual quality of the master data.

Our Odoo migration for the EUDR commodity importer began with a six-week assessment of supplier records and master-data quality before a single line of Odoo configuration was written. The finding was uncomfortable: roughly three duplicate vendor records per supplier across the legacy ERP, plus inconsistent country-of-origin coding that would have made the Dec 30 2026 EUDR submission impossible. That assessment reshaped the entire programme — we agreed which records to migrate, which to merge, and which to Retire before cutover. Inventory done properly here is what makes every later phase tractable.

The 6R label drives the architecture. Refactor and Replatform demand specific patterns; Rehost is mostly an infrastructure exercise. Pick wrong here and the rest of the programme inherits the mistake.

On the Odoo programme we used a strangler-fig pattern — the legacy ERP continued to serve operations while we routed individual capabilities (supplier onboarding, plot-level geolocation, EUDR due-diligence statements) into Odoo module-by-module. Sentinel-2 satellite data flowed into the new system from day one without disturbing the old.

On the agricultural data engineering programme, the architecture decision was different again. Field officers needed NDVI and EVI satellite indices in remote tea-growing regions with intermittent connectivity, so we chose an offline-first PWA with a PostgreSQL backend and Airflow orchestrating the ingest pipelines. A microservices-everywhere reflex would have made it unusable in the field.

A modernised system is not safe to switch on at full volume. Feature flags and shadow mode let you run the new path in production while the old one remains authoritative — so you can compare, not guess.

On the data engineering programme, the new ingest pipeline ran in shadow mode against the legacy spreadsheets for several weeks before any field officer trusted a reading from it. Discrepancies between the two were triaged daily. We use LaunchDarkly or Unleash for application-tier flags depending on the client's existing stack, and a hand-rolled cohort table where finer control is needed.

On the IDP pipeline for the sustainability certification body, we deliberately chose scikit-learn over deep learning so the model was small enough to roll out behind a human-in-the-loop gate — OCR plus NLP extracting fields, a reviewer confirming. Risk control is sometimes a model choice, not just a deployment trick.

This is where most modernisations actually fail. Code can be rewritten; data can't be re-derived once it's wrong. We treat data migration as a first-class workstream with its own architecture, not a footnote at the end.

Our toolkit is the usual practitioner kit: CDC (change data capture) feeding the new store while the old one stays live, dual-write at the application tier where transactional consistency matters, and Liquibase or Flyway for versioned schema migrations so every change is reproducible and reversible.

For the TR Capital portfolio management platform, the data migration had to preserve a full SEBI audit trail across trade reconciliation and corporate-action processing — every historical row needed to map cleanly into the new schema with provenance intact. We staged migrations into a parallel schema, reconciled balances and corporate-action events end-to-end, and only flipped the read path once reconciliation was clean for three consecutive trading days.

Cutover is the moment the new system becomes authoritative. Done well, it's anticlimactic. Done poorly, it's the postmortem your CTO writes for the board.

On the East Africa farmer programme— 10,000+ smallholders, intermittent connectivity, sql.js and OPFS holding state on-device — we ran an extended shadow-mode window where the new PWA captured readings in parallel with the legacy paper-and-spreadsheet flow. OTP-based account recovery and HDOP filtering for GPS quality had to be proven in the field, not just in the lab. The cutover decision wasn't a date on a plan; it was a checklist of conditions, including a sync-conflict rate that had to stay flat for two weeks.

Every cutover plan we ship includes an explicit rollback step. If reconciliation breaks, the feature flag flips back and the legacy path resumes inside minutes. Reversibility is the whole point of the previous four phases.

The day after cutover is when modernisation either compounds into an organisational asset or quietly decays back into the next generation of legacy. Handoff is the bridge.

On the data engineering programme we treated the production handoff as deliberately as the build. Airflow DAGs were documented with their failure modes, not just their happy paths. Runbooks covered Sentinel-2 ingest failures, NDVI computation edge cases for cloudy tiles, and the escalation path when a field officer's offline cache wouldn't sync. SLOs were agreed with the client's operations team and instrumented before sign-off.

A pipeline only becomes an organisational asset — rather than an engineering artefact stranded on the team that built it — when the people who run it day-to-day understand why it's shaped the way it is. Phase six is where we make that understanding stick.