Written by:
Last Published:
01 September 2026
•
Infrastructure costs a lot. Your finance team flags the quarterly bill. You look at the line item (vendor licensing, mostly) and wonder: what if we just rewrote the whole thing?
Is a legacy modernization case study always about expensive rewrites? No.
One maritime communication platform, Sedna, proved it. In a phased approach that kept the team lean and the risk manageable, they cut infrastructure costs by 80%. No multi-year rewrite. No throwing out the old and starting fresh. Instead, a throughout refactor of the systems that hurt most.
This is what the CTOs I know actually need to hear. Not the enterprise consulting playbook neither the"best practices" distilled from a thousand companies. You need to her the real story: what changed, why it worked, and what you should do first.
Let's talk about Sedna's approach, the technical decisions that mattered, and how to run your own modernisation without betting the company.
Direct answer: Legacy modernisation is the process of refactoring outdated systems (typically monoliths carrying technical debt or vendor-heavy platforms) to reduce cost, improve scalability, and regain technical autonomy. It's not a rewrite but a strategic retrofit.
Think of it like renovating an old house instead of demolishing it. You shore up the foundation, replace the wiring, keep the bones intact. The building stays liveable throughout. You're not moving out while reconstruction happens.
In software terms, this means taking systems your team depends on (usually ones that are expensive to maintain or run) and modernising them incrementally. You might replace a costly third-party tool with in-house code or you might shift workloads from dedicated infrastructure to serverless. Maybe you might simply clean up the technical debt that's been gathering interest for five years.
This matters because it's different from what most companies attempt. A full rewrite assumes you have time and budget to stop everything else. A lift-and-shift to the cloud assumes your architecture fits AWS out of the box. Modernisation is quieter and iterative. It lets you prove value before committing billions to the next phase.
Sedna built maritime communication products (Stream and Pulse) that help shipping and supply chain teams coordinate. (See the full case study.) It involved a growing product, growing team, growing complexity... and a growing bill.
The pain point was Tray.io, a third-party workflow integration platform, that was doing important work. like connecting external systems, processing data, orchestrating the business logic that ran between services. But as the company scaled, so did the licensing costs. More workflows meant higher fees, more complexity meant more intricate Tray.io configurations, and more maintenance burden on the core engineering team.
But here's the trap: the workflows were outside the codebase. They lived in Tray.io's interface, so engineers couldn't version them, test them in CI/CD, or review them in pull requests. If something broke, ops couldn't just roll back a deployment, but you had to log into the vendor platform and debug in production.
So, Sedna faced the question most growing companies do: Do we just accept the cost and keep moving, or do we take six months to solve it?
They chose the latter. But they didn't jump straight to a full migration. They optimised first.
The first phase of Sedna's modernisation was strategic optimisation (streamlining existing Tray.io workflows and eliminating unnecessary complexity before any rewrite). This paid for itself and de-risked the migration.
Most companies skip this step. They see the cost, see a potential solution, and swing for the fences. Sedna didn't. They spent four weeks auditing their Tray.io workflows, removing redundant steps, consolidating similar patterns, and squeezing the platform harder.
The payoff was immediate. Licensing costs dropped just from running a tighter ship. The engineering team got hands-on with the workflows (what existed, what was broken, what actually mattered). And crucially, they bought proof of concept. When leadership saw early cost savings, the business case for Phase 2 became obvious.
This is the first rule of modernisation: optimise before you migrate. It costs less, de-risks the next phase, and often buys you enough breathing room that you're not in crisis mode while rebuilding core systems.
Sedna built a custom solution hosted on AWS using Lambda functions for workflow orchestration, replacing Tray.io's vendor platform with first-party code deployed via CI/CD and Terraform. The result was full code ownership, versioning, testability, and an 80% cut in infrastructure costs.
The migration was careful. Sedna brought in specialists (a backend engineer and a full-stack developer from Imaginary Cloud) alongside their core team to move workflows from Tray.io to AWS Lambda step by step.
Here's the architecture: each Tray.io workflow became a set of Lambda functions. AWS Step Functions orchestrated the pipeline (managing retries, error handling, state transitions). The functions themselves were pure JavaScript, stored in Git, versioned and tested like any other code.
This shift had three immediate benefits:
- First, cost. A serverless model means you pay for execution time, not fixed licensing.
- Second, ownership. Workflows are now in your codebase, reviewable in pull requests, testable before production.
- Third, velocity. When engineering wants to ship a new feature, they're not blocked waiting for a Tray.io workflow designed by an operations person.
The result was an 80% reduction in what Sedna was spending on vendor licensing and related infrastructure. But more than the number, the team had reclaimed autonomy.
Cost reduction in legacy modernisation typically comes from three levers: eliminating expensive third-party tools, shifting workloads to serverless economics, and redeploying engineering capacity from maintenance to features.
Since understanding these levers is how you build your own modernisation strategy, let's break down each one.
Tray.io was doing important work, but it was also a fixed cost that scaled with complexity. More workflows meant higher cost. And more sophistication meant higher tier. The platform became a ceiling on how much integration the business could afford to do.
By migrating to AWS Lambda, Sedna shifted from "pay for features" to "pay for execution." A workflow that runs 100 times a day costs almost nothing. A workflow that runs once an hour costs nearly as little. You're paying for compute consumed, not for a vendor's product tier.
This is the first lever: audit which third-party tools are expensive and owned versus cheap and commodified. Your identity provider? Probably worth the cost. Your workflow orchestration? Candidates for in-house.
Lambda pricing is huge to your initial intuition. It feels expensive per invocation. But it's generous on volume. If you run a thousand workflow executions a day, Lambda costs less than a single dedicated server.
The key is this: serverless eliminates the fixed cost of infrastructure. You're not paying for compute whether the workflows run or not. On a Tuesday morning when workflows are quiet, you pay almost nothing. On a Friday afternoon when integrations fire, the cost scales with demand.
For Sedna, this shifted the cost structure from monthly licensing to pay-as-you-go cloud compute. What this meant in the end? Less 80%.
Here's the hidden lever that finance teams often miss. When workflows were in Tray.io, ops had to manage them, monitor them, troubleshoot them when they failed, and update them when integrations changed.
With Lambda, all that becomes the core team's responsibility. And because it's in Git, versioned, and testable, it's actually less work. The engineering team went from "maintaining a vendor platform" to "owning a codebase." The team's time went from reactive, that is, fixing broken integrations, to proactive, by shipping new capabilities.
Sedna's engagement included one backend engineer and one full-stack developer for about six months, and that's a real cost. But the payoff was lasting, since the core team was permanently unblocked.
Sedna migrated workflow orchestration from Tray.io to AWS Lambda using JavaScript and Kotlin, containerising functions for portability and building CI/CD pipelines with Terraform. The shift from vendor platform to first-party code gave them ownership and scalability.
Let's dig into how they actually did this, because the technical pattern matters.
Tray.io workflows were monolithic (big configurations that did multiple things in sequence). Lambda workflows are granular. Each step becomes a function.
Imagine this: Customer data arrives. A Lambda function validates the data. If valid, another function loads it into the database. If invalid, a third function logs the error and notifies ops. AWS Step Functions orchestrates this pipeline, by deciding which function runs next based on the previous one's output.
Why this pattern? Testability. Each function is small, has one job, and can be unit tested in isolation. A developer can run npm test locally and verify the logic before deployment. If you try that with a Tray.io workflow, you'll be stuck debugging in production.
Backend: JavaScript on Lambda. Pure Node.js with no vendor-specific frameworks. If Sedna ever needs to migrate away from AWS, the functions work anywhere Node.js runs.
Infrastructure: AWS Lambda for compute, Step Functions for orchestration, RDS or DynamoDB for data, API Gateway for external integrations.
Deployment: Terraform for infrastructure-as-code (reproducible, version-controlled). GitHub Actions for CI/CD. When a developer pushes a workflow update, the pipeline runs tests and, if they pass, deploys to production.
Monitoring: CloudWatch for logs, X-Ray for distributed tracing. When a workflow fails, ops can see exactly which function errored and why.
Here are the gotchas Sedna hit and solved.
Cold starts. Lambda functions take a moment to boot when invoked after idle time. For workflows that need to respond instantly, this matters. Sedna mitigated this with provisioned concurrency on critical paths. You pay a bit more to keep functions warm. Worth it for latency-sensitive integrations.
State management. Workflows are stateful. They need to remember what step they're on, what data they're processing. Lambda is stateless. AWS Step Functions handles this, storing the workflow state in its own database. It's reliable, but it's one more service to understand.
Error handling. In Tray.io, workflow errors were often silent or opaque. In Lambda, you need to explicitly define retry logic, dead-letter queues, and error notifications. Sedna built this into their Step Functions template. Every workflow gets the same retry strategy (three attempts, exponential backoff) unless overridden.
Testing before production. This is where Lambda shines. Sedna's team now writes tests for workflows like any other code. Before a deploy, they run the full pipeline against staging data. It's slower than Tray.io's UI, but it's vastly more reliable.
Before you assume Lambda is right for everything, let's talk about the limits.
Long-running processes. Lambda has a 15-minute timeout. If your workflow is still running after 15 minutes, you need a different architecture (Fargate, Kubernetes, traditional VMs).
High-volume, extremely consistent workloads. If you're processing 10 million events a day with perfectly predictable load, a dedicated server or Kubernetes cluster might be cheaper than serverless. The math flips when your workload is consistent enough that you're always paying for your minimum capacity.
Highly stateful applications. Lambda is stateless. If your workflow needs to maintain complex state across steps, you're moving that burden to a database or external state store. It works, but it adds complexity.
Sedna's workflows, like integrations between external systems, were perfect for Lambda. Sporadic, short-lived, event-driven. If your profile is different, dig into the cost comparison.
Most modernisation projects stall from human decisions, such as rip-and-replace without testing, ignoring new vendor lock-in, underestimating team bandwidth, scope creep, and missing success metrics. Phased approaches with clear gates prevent all five.
The temptation is real: "Let's rewrite the whole thing in [new tech]." It feels cleaner, faster, more satisfying than incremental refactoring.
Sedna rejected this. Phase 1 (optimisation) validated the business case and de-risked Phase 2. When leadership saw early cost savings, the case for migration was obvious. When engineering hit implementation problems, they had real data to course-correct.
If you jump straight to a full rewrite, you're betting the company on a timeline estimate made by people who've never done this exact thing before. Start small, pilot a single workload, and prove it works.
You escaped Tray.io dependency, but now you're dependent on AWS.
This is a real concern, but it's manageable. Sedna's approach: containerise the functions (Docker), use standard libraries (Node.js, no AWS SDK in the core logic), and avoid AWS-specific services where possible. If AWS ever becomes problematic, the functions can run on Google Cloud Run or Azure Functions with minimal changes.
The difference between good and bad lock-in is portability. Good lock-in means you're using a service (AWS Lambda) that multiple providers offer. Bad lock-in means your entire business logic depends on a vendor-specific API you can't replicate elsewhere.
Your core team is busy because they're shipping features, fixing bugs, responding to customers. Now you want them to modernise infrastructure, too?
It doesn't work and you may end up with half-finished code, missed deadlines, and a core team too stressed to think clearly. But Sedna brought in specialists from Imaginary Cloud for six months. They worked alongside the core team, built the patterns, and then the core team took ownership.
If you're doing this in-house with no external help, budget for it. Dedicate engineers to modernisation. Don't ask people to do it in the margins.
Sedna stayed focused. Phase 1 optimised the existing Tray.io setup. Phase 2 migrated workflows to Lambda. That's it. Only after both phases were done did they add new features (workflow versioning, All Teams support, Sent Messages capability).
Each new scope item adds risk. Keep your modernisation focused. You can ship features and technical improvements in the same sprint, but don't let them become entangled.
Define upfront: What are you measuring? Cost per workflow? Latency? Error rate? Team hours spent on maintenance?
Sedna had clear metrics. Cost reduction (target: 70%, achieved: 80%). Time to deploy a new workflow (before: ops bottleneck, after: same-day). Error rate (maintained, then improved). When you can point to these numbers, you have proof for the next modernisation initiative.
Start with a 4-week audit: map all legacy systems, identify cost drivers and technical debt, prioritise by impact and risk. Then pilot a single workload, by proving cost savings and technical feasibility, before scaling.
If you're serious about modernisation, here's the actual roadmap that Sedna ran, adapted for your context.
Do this first. Don't skip it.
List every legacy system, third-party tool, and integration your business depends on. For each one, record: annual cost, team hours spent maintaining it, and criticality (can we live without it? Does it block product features?).
Run this audit across engineering, operations, and finance. You'll be surprised what you find, such as old contracts still being paid, tools no one remembers why they use, infrastructure running the same workload twice because nobody documented it.
Deliverable: A prioritised list of migration candidates. Use this matrix: cost impact (high/medium/low) vs. technical risk (high/medium/low). Start with high cost + low risk. Avoid high cost + high risk until you've proven the approach works.
Outcome by end of week 4: Buy-in from leadership. You know what you're modernising and why.
While you're planning the migration, squeeze the existing system. Remove redundant workflows (Sedna's case), refactor expensive queries, upgrade outdated dependencies, delete code nobody's touched in two years.
This phase is unglamorous, but it's where most companies find 20–30% cost savings with zero risk. And it proves to the business that modernisation is real.
Deliverable: First cost reduction. Early momentum. Proof that your team can execute.
While optimising, plan the migration for your pilot workload.
Select a workload that's high-ROI but low-risk. For Sedna, this was workflow orchestration: important to the business, but isolated from core product. Don't pilot on your main database or your authentication layer. Pick something self-contained.
Proof of concept: Migrate one workflow end-to-end. Measure: cost, latency, error rate, team time invested. Does the new approach work? Is it cheaper? Is it faster? Document the pattern.
Team: Senior architect and specialists (if you're bringing in external help) plus one core team member. The core team person learns the pattern and owns it after the specialists leave.
Deliverable: A validated approach. Cost model. Timeline for Phase 2. Evidence that this will work for the real thing.
Outcome by end of week 12: Green light to migrate everything else.
Replicate the pilot pattern across all workloads. Staged rollout: shadow (new system runs in parallel, output is ignored), then canary (5% of traffic goes to new system, 95% to old), then full cutover (all traffic to new system).
Run old and new in parallel for two weeks. If something goes wrong, rollback is instant—just flip the traffic switch. This safety net is worth the short-term operational complexity.
Deliverable: All workloads migrated. Cost target achieved. Zero production incidents.
Modernisation isn't done when you've migrated everything. It's done when you've optimised the new system and claimed the benefits.
Monitor CloudWatch, cost attribution, performance baselines. Tune: reserved capacity for predictable workloads, architectural tweaks based on production patterns, feature requests that are now possible (Sedna added workflow versioning and new message support here).
Document what worked, what didn't, patterns for the next modernisation.
Week 4: Go/no-go based on audit. Is there enough cost impact to justify the effort? Is the team aligned?
Week 12: Go/no-go based on pilot results. Did the new approach work? Is it cheaper? Does the team have confidence?
If either answer is no, you haven't failed. You've learned. Adjust and try again. Sedna could have discovered their pilot didn't work and switched approaches. It did work, so Phase 2 was obvious.
Depends on scale. Sedna's two-phase approach took about six months (optimisation + migration). A larger system could take 12–18 months. The key isn't speed; it's delivering value at each phase rather than a big-bang rewrite that takes two years and lands with zero buffer.
Running in phases means each phase pays for the next. Phase 1 optimisation might fund Phase 2 migration. Phase 2 migration buys the team time to ship Phase 3 features. You're not betting billions upfront. You're investing incrementally.
You run the new system in parallel with the old one until you're confident. If production breaks, you flip back to the old system instantly. You haven't deleted anything. Sedna kept Tray.io running for two weeks into the Lambda migration as a safety net.
Parallel running is operationally heavier (you're running both systems, monitoring both, potentially debugging both). But it's the insurance policy that makes leadership sleep at night. Worth it.
Model ROI early. Phase 1 optimisation often pays for Phase 2. Show leadership: current annual licensing costs, projected savings, payback period, secondary benefits (faster feature delivery, lower ops burden). Sedna's 80% cost cut made the business case obvious—payback in three months, profit for years after.
If you can't make the ROI case, the modernisation isn't urgent enough. Put it on the roadmap, optimize where you can cheaply, and revisit next quarter.
Depends on team expertise. If your team has deep serverless and AWS knowledge, in-house is faster and cheaper. If not, external help de-risks the timeline and accelerates learning.
The Managed Teams model Sedna used (specialists embedded with the core team for a defined period) is a middle ground. You get execution speed, knowledge transfer, and lasting capability in your team. Headcount-wise, it's often cheaper than hiring full-time engineers for a six-month project.
Hybrid is fine. Migrate the costliest, most problematic workloads to serverless; keep stable, high-volume workloads on infrastructure that's already optimised for that load. Avoid all-or-nothing thinking.
A common pattern: migrate integrations and background jobs to Lambda (serverless is great for these), keep databases and core services on managed infrastructure. You get cost reduction and capability gains without the risk of a complete architecture rewrite.
Containerise your functions (Docker containers are portable). Use managed databases with standard APIs (not Aurora-specific features). Avoid AWS-specific frameworks in your core business logic.
Sedna's Lambda functions are pure JavaScript using standard Node.js libraries. The AWS SDK calls are isolated in infrastructure code. If the business ever decides to move to Google Cloud, the functions work on Cloud Run with minimal changes. The infrastructure code would need rewriting, but the actual logic is portable.
Legacy modernisation is not binary: rewrite everything or accept cost bloat. It's a strategic retrofit.
Sedna's 80% cost cut came from three things: eliminating vendor dependency (Tray.io licensing gone), shifting to serverless economics (pay for execution, not fixed capacity), and freeing the team to deliver new features (workflows now in code, testable, fast to deploy).
The lesson for CTOs: Start with what hurts most: cost, speed, reliability. Then, optimise first to de-risk and build momentum. Then migrate. Then optimise again. Each phase justifies the next.
Most of you are paying too much for legacy systems that are too slow to change. If that's your situation, this is your permission to act on modernisation. Run an audit. Pick a pilot. Prove it works. And then, scale.
The 80% cut Sedna achieved isn't magic. It's discipline: phased approach, clear ROI, team support, and the courage to move when the business case is solid.
Your turn.
Ready to modernise your legacy systems? Contact Imaginary Cloud to discuss your modernisation roadmap. We help you achieve lasting cost reduction and technical autonomy.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
Inês Silva is a Project Manager with over four years of experience writing about software delivery, agile methodologies, and tech leadership. Because she started her career as a developer, Inês brings a real, deeply technical understanding to the management side of things. She loves bridging the gap between big-picture business strategy and day-to-day engineering execution, and she's passionate about sharing practical tips that help teams collaborate better and ship great products.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
