Re-platforming a live maritime ERP without stopping work
After five years in production, Speed Logistics Marine's ERP had outgrown the stack it was built on. We moved it to a single enterprise stack in 12 months while the business kept running, and left it free of vendor lock-in.
Five years of growth turned the stack into a ceiling
MetaProject designed and launched the Speed Logistics Marine ERP in 2019, and supported it for the next five years: targeted feature work, regulatory changes and regular audits. The business grew over that time. Shipping volumes rose and the company's structure became more complex.
The platform accumulated technical debt as it kept pace, and the stack it was built on, Python and Django with a Vue 2 frontend and hand-written deployment scripts, started to limit how far it could scale. Patching it would keep it running. It would not let it grow.
The brief: pick the modernisation path with the most predictable long-term cost, then carry it out without interrupting a logistics operator that never stops.
Rules drifted between departments
Business rules had fallen out of sync between departments, and the technical documentation no longer matched the system people relied on.
Every release was a manual risk
Deployments ran on hand-written bash scripts and releases were checked by hand. The inherited failover setup was no longer enough for the load.
A deadline hidden in the stack
Staying on the old architecture would, within two to three years, slow development sharply and force an emergency shutdown to replace the whole system.
Four decisions that made the migration safe
Replace the whole stack, not piece by piece
We weighed three paths with the client's management. Staying on the current architecture was the cheapest in the short term. A module-by-module hybrid would leave services on different technologies, joined through incompatible interfaces, and raise the total cost of ownership. A full move to one enterprise stack cost more at the design stage and was the only option with predictable long-term development.
Design first, and get it signed off
The first two months went on the legacy business logic: we systematised it and formalised how departments work together, which fixed the rule drift at its source. Architecture blueprints, API specifications and a wave-by-wave data migration plan followed, and the project passed the client's Architecture Review Board before any code moved.
Clean five years of history before moving it
Order-handling rules had changed several times since 2019, so the legacy database held structural inconsistencies. Instead of copying them into the new platform, ETL scripts validated and normalised the data automatically before import, and databases and file storage moved over in waves alongside the build.
Switch over without a stop
A two-way sync kept the old and new databases aligned during the final month, and every key scenario went through full end-to-end testing. Users then moved to the new ERP while ships, crews and payments kept moving. For a logistics operator, a planned outage is not an option.
Months 1–2 · Audit and architecture
Blueprints, API specs, wave plan, ARB sign-off.
Months 3–11 · Build and data migration
Core modules on .NET 10, integrations rebuilt, data moved in waves.
Month 12 · Stabilisation and cutover
Two-way database sync, full E2E testing, switch with no stop.
After cutover · Run and evolve
MetaProject keeps supporting the platform.
Replaceable on paper, still the team that runs it
The migration ended with a system SLM fully owns: complete technical documentation, OpenAPI descriptions of every REST API and Helm charts for deployment. Any qualified engineering team could take it over. We built it that way on purpose.
MetaProject continues to support and evolve the platform, the same partnership that began with the original build in 2019. The integration layer (mail, push notifications, SMS gateways and external APIs) now runs as isolated services, so the next change to any of them stays contained.
2019
original build, supported ever since
12 months
from audit to full cutover
<5%
change failure rate after the move
0
stops to operations during the switch
<5%
change failure rate, with automated checks in CI/CD
+20%
faster lead time for changes
0
stops to operations during the cutover
5 years
of historical data validated and migrated
12 months
from audit to cutover
A full re-platforming of the SLM ERP: core modules, databases and file storage, the spaCy NER language module, and integrations with Mailgun, OneSignal, Google APIs and SMS gateways rebuilt as isolated services.
From Python 3.9 / Django 3.1 · Vue 2 · Celery · bash scripts to .NET 10 (C#) · Next.js 16 with Feature-Sliced Design · PostgreSQL · Redis · Kafka · Kubernetes · GitHub Actions + ArgoCD · SonarQube · Playwright · Snyk · Trivy · gitleaks
Questions about this project
When is a full re-platforming better than a module-by-module migration?
When a hybrid would leave services on different technologies joined through incompatible interfaces. For SLM a gradual migration would have raised the total cost of ownership, and staying put would have forced an emergency replacement within two to three years. A full move cost more at the design stage but was the only option with predictable long-term development.
How do you migrate a live ERP without stopping operations?
Design first, then move data in waves, then cut over behind a two-way sync. For SLM, two months of audit and architecture came before any code moved, five years of history were cleaned by ETL scripts before import, and a two-way database sync plus full end-to-end testing let users switch with no stop to logistics operations.
What changed in delivery after the migration?
Change failure rate fell below 5% because every release now passes SonarQube, Snyk and Playwright checks, and lead time for changes improved by 20% thanks to one standard stack and GitOps deployments through ArgoCD.
Is the client locked in to MetaProject?
No, by design. SLM received full technical documentation, OpenAPI descriptions of every REST API and Helm charts for deployment, so any qualified team could take the platform over. MetaProject still supports it, as it has since the original build in 2019.
See more cases
Is your stack becoming the limit on your business?
Tell us what you are building. We will come back with an honest view of how we would approach it.