The migration challenge

A live API is a contract. Partners had integrated against the existing service - a legacy VB.NET/SOAP application - and any breaking change risked interrupting the flow of data they relied on. The rebuild therefore had two goals that usually pull in opposite directions: modernise the platform completely, and change nothing that existing consumers could see.

A modern serverless API

We built the new API on Amazon API Gateway's HTTP API, with each endpoint served by its own single-purpose AWS Lambda function. A single-table Amazon DynamoDB design holds the service's own domain - partners, brands and access rules - alongside a fast cache of the package data itself, for predictable low-latency reads at any scale. Access is gated per partner with API keys, and a purpose-built admin interface lets the team manage partners and configuration directly.

  • Modern JSON/HTTP interface for new integrations, defined by a clear API specification.
  • Serverless throughout - no servers to run, and cost scales with actual usage.
  • Single-table DynamoDB for consistent, low-latency reads under variable load.
  • Per-partner API keys for secure, controlled, multi-tenant access.

Zero-downtime migration

The key to a seamless cutover was backward compatibility. Alongside the modern JSON interface, the new service exposes a compatibility layer that speaks the same SOAP/XML protocol as the legacy API - serving the same contract, operation for operation. Existing consumers continued to call the service exactly as before, unaware that everything behind the interface had been rebuilt, while new integrations could adopt the modern interface at their own pace.

To give everyone confidence in the switch, we built a harness that fired identical queries at the old service and the new one in parallel and put their responses side by side - confirming the rebuilt API returned equivalent results before anything was moved across.

Cost-optimised by design

Because serverless bills per request, efficiency is a design concern rather than an afterthought. Two ideas do most of the work. First, the service resolves its filtering rules before it fans out to the data store: any request combination that a rule excludes outright never triggers a function invocation at all, and the rest are refined afterwards. Second, each request carries a response-time budget - the service fans a query out across every relevant combination and returns whatever has resolved within that budget, so it honours a real latency target rather than waiting on the slowest shard. The effect is a service that is both faster to respond and cheaper to run.

Key AWS services

  • Amazon API Gateway (HTTP API): the modern, low-overhead front door to the service.
  • AWS Lambda: a dedicated serverless function behind each endpoint.
  • Amazon DynamoDB: a single-table design for fast, scalable data access.
  • Amazon S3: storage for the admin interface's assets and supporting files.

Results: modernised, without disruption

  • No consumer disruption: existing partners kept working unchanged throughout the migration.
  • A modern interface: new integrations use a clean, well-documented HTTP/JSON API.
  • Lower running costs: serverless compute and query optimisation cut the cost of every request.
  • Latency you can budget for: each request returns within a response-time target rather than blocking on the slowest lookup.
  • Elastic scale: the service handles variable demand automatically, with no capacity to manage.
  • Simple administration: partner and configuration management is handled through a purpose-built admin interface.

About Si Novi: serverless API specialists

We design and build serverless APIs and cloud-native applications on AWS, with a particular focus on modernising legacy systems safely.

By combining modern architecture with careful, backward-compatible migration, we help businesses like Distribute move their platforms forward without putting the integrations their partners depend on at risk.