How to Migrate an E-Commerce Platform from AWS to Singtel Cloud Without Losing Three Months of Sales
How to Migrate an E-Commerce Platform from AWS to Singtel Cloud Without Losing Three Months of Sales
The decision to leave AWS is rarely driven by a single failure. For the team behind an online retailer of specialty Asian kitchenware based in Singapore, it was a slow accumulation of small frustrations: a latency graph that crept up during peak hours like a fever chart, monthly bills that grew faster than revenue, and a growing sense that the infrastructure had become more complex than the business it served.
The company—a mid-size operation shipping across Southeast Asia and into Australia—had been on AWS since launch in 2019. By early 2023, they were spending around S$4,200 a month on compute, storage, and data transfer, with a significant portion going to CloudFront for content delivery to customers in Indonesia, the Philippines, and Vietnam. The architecture was standard enough: an Application Load Balancer fronting a cluster of t3.medium instances, RDS for the database, S3 for product images. Nothing exotic. Nothing obviously broken.
Then the CFO sent a single email with a subject line that read, simply: “AWS costs.”
That was the real starting point. Not a technical trigger. A financial one.
The CFO’s Email Was Three Weeks Ahead of the First Latency Probe
The mistake most teams make, according to Yusuf, a cloud architect who consults for e-commerce firms in the region, is moving for cost reasons alone. “You benchmark the price, you don’t benchmark the experience. The CFO sees a cheaper option and the engineering team says sure, we can make it work. But nobody asks how long an API call actually takes from Jakarta, or Manila, or Ho Chi Minh City, because nobody was measuring that before.”
The kitchenware retailer did measure it, but only after the decision to migrate had already been made. That ordering—decision first, then measurement—is itself a kind of failure, and it showed up later in ways that cost more than the projected savings.
For three weeks before any migration work began, the team ran a latency probe from their production environment to test endpoints hosted on Singtel Cloud’s infrastructure, which had been selected because of the telco’s aggressive pricing for Southeast Asian traffic and its existing data centre presence in Singapore. The probe measured round-trip time from six locations: Singapore, Jakarta, Manila, Bangkok, Ho Chi Minh City, and Sydney. The results were uneven. In Singapore, Singtel Cloud was consistently 8–12 milliseconds faster than AWS, thanks to a local network path that stayed entirely within Singtel’s own backbone. In Jakarta and Manila, the difference was negligible—within 5 ms either way. But in Ho Chi Minh City, Singtel Cloud was 45 ms slower. In Sydney, it was 60 ms slower.
The team documented this and proceeded anyway. The CFO’s cost analysis had shown a potential 30% reduction in the monthly bill. The latency trade-off in two markets was considered acceptable.
“It’s the kind of trade-off that looks fine on a spreadsheet and then starts feeling different when a customer in Sydney tries to load a product page,” Yusuf said. “Three seconds of extra load time changes conversion rates by measurable percentages. We know this. But in a meeting, the spreadsheet always wins.”
Four Hours of Normal, Then a Founder’s 6 a.m. Panic
This is where the first real mistake happened, and it’s the kind of error that experienced teams make precisely because they are experienced.
The retailer’s engineers lifted the application onto Singtel Cloud’s virtual machines—a direct port of the AWS setup, running on equivalent-spec instances—and expected it to behave identically. It didn’t.
The database, a PostgreSQL instance that had been running on RDS with 2 vCPUs and 8 GB of memory, was moved to a comparable Singtel Cloud-managed database service. The connection strings were updated. The application started. The test suite passed. Everything looked normal for about four hours.
Then the product image loading slowed to the point where page load times in Singapore, the team’s home market, climbed past 4.5 seconds. That’s the kind of number that gets a founder out of bed before 6 a.m.
The culprit was the database connection pooling configuration, which had been tuned for AWS’s network characteristics—specifically, the way RDS handled ephemeral port exhaustion under load. On Singtel Cloud’s managed database, the same pool size and timeout settings produced a different behaviour: connections accumulated faster than they were released, creating a backlog that eventually queued every query, including the simple SELECT statements that populated product thumbnails.
“We assumed the defaults would work because they’d always worked,” said Priya, who was the lead engineer at the time. “That assumption cost us about 42 man-hours of debugging spread over a week and a half. We didn’t even think to check the connection pool. The error logs didn’t show a clear failure—they just showed slowness.”
The fix was straightforward once identified: reduce the pool size by 40% and shorten the connection timeout. But the week and a half of degraded performance coincided with a promotional event—the Lunar New Year sale—during which the site’s conversion rate dropped from 3.1% to 1.8%. The CFO’s spreadsheet had not included a line item for lost sales during migration.
The Vietnamese Traffic That Ended Up On a Permanent Split
Most migration guides recommend a gradual cutover—10% of traffic, then 25%, then 50%, then full. That’s what the retailer did. But they did it in geographic order, starting with Singapore traffic, which happened to be the easiest path for Singtel Cloud. The first few shifts looked great. Response times improved. The CFO saw early savings accumulating. Confidence grew.
The mistake was deferring the difficult test to the end. When they finally shifted the first 10% of Vietnamese traffic to the new infrastructure, the latency in Ho Chi Minh City jumped from an already-uncomfortable 145 ms to 210 ms. On Singtel Cloud’s network, that traffic was being backhauled through Singapore before reaching the end user, because the cloud provider’s direct peering in Vietnam was less developed than AWS’s.
There are two ways to handle this. One is to negotiate with the cloud provider for better local peering, which Singtel Cloud did eventually improve after the retailer’s escalation. The other, and the smarter one, is to test the worst path first during the migration—shift traffic from the weakest market before shifting from the strongest one. That way, the discovery happens when the stakes are lower and the rollback is easier.
The retailer ended up keeping roughly 30% of Vietnamese traffic on AWS as a permanent split, using a geo-routing layer that directed users based on latency thresholds rather than a simple country-based rule. It wasn’t the clean architecture they’d planned. It worked, though, and it cost less than a full rollback would have.
The Batch Job on Someone Else’s VM That Slowed the Product Pages
About six weeks into the migration, the kitchenware retailer hit an afternoon where the site load time in Singapore, which had been consistently fast on Singtel Cloud, suddenly doubled. No deployment had happened. No configuration change was recorded. The monitoring dashboards showed normal CPU and memory. The database had no slow queries. The network graphs looked flat.
The root cause was something that wouldn’t have shown up in any standard AWS migration checklist: Singtel Cloud’s virtual machine hypervisor was using a noisy-neighbour scheduling strategy for disk I/O, and a heavy batch job running on a different customer’s VM on the same physical host—a data processing workload that started every afternoon at 2 p.m.—was consuming the shared storage bandwidth.
The retailer’s VMs were running GP2-equivalent SSD volumes, which on Singtel Cloud shared a throughput pool with other tenants on the same host. The batch job didn’t show up in the retailer’s metrics because it wasn’t their process. It showed up only as a mysterious latency spike at the storage layer, visible if and only if someone knew to look at the storage queue depth on the hypervisor level—a metric that Singtel Cloud exposed only through a separate API endpoint, not in the default monitoring dashboard.
“We had to call support and ask them to check their own host metrics,” Priya recalled. “It took three calls and a ticket escalation before someone actually looked. The problem wasn’t us. But it was on our bill.”
The fix was to reserve dedicated IOPS for the database volume, which Singtel Cloud offered as a premium add-on for an additional S$180 a month. The alternative was to migrate to a dedicated instance—the equivalent of an AWS dedicated host—which would have cost more than the IOPS reservation. The team chose the cheaper option. The latency spike never returned.
The lesson, according to Yusuf, is that monitoring on a new cloud provider isn’t the same as monitoring on the one you left. “You need to know what metrics the provider exposes, which ones they hide, and which ones they charge extra to see. That information is usually buried in a pricing page or a support article. Nobody reads it until something breaks.”
The S$18,000 the CFO Didn’t See Coming
Three months after the first cutover, the kitchenware retailer’s monthly bill on Singtel Cloud was S$2,950—a 30% reduction from the AWS peak. The CFO was satisfied. The engineering team was not, because the total cost of migration, including the engineered hours, the lost sales during the Lunar New Year degradation, the support escalations, and the IOPS reservation, came to roughly S$18,000 in non-infrastructure spending that hadn’t been budgeted.
That’s a number that needs context. S$18,000 is less than four months of the cost differential between the two providers. By any reasonable calculation, the migration paid for itself within half a year. But the way it was spent—unexpectedly, reactively, in small increments that felt avoidable—created friction between the finance and engineering teams that took longer to resolve than the migration itself.
Price isn’t a single number. It’s a schedule of numbers, some of which you see in advance and some of which you discover along the way. The kitchenware retailer learned that the hard way, and they aren’t alone.
There’s also a softer cost that rarely gets discussed: the trust of the development team. During the weeks of unexplained slowness, the engineers were asked to investigate and fix problems that turned out to be outside their control—hypervisor contention, incomplete peering, pool settings that only broke on a different cloud. They did the work, but the experience eroded their confidence in the migration decision itself. One of them, a backend developer, quietly moved his personal side project back to AWS. “I just didn’t trust the network anymore. Logically, I knew it was fine. But emotionally, I kept expecting something else to go wrong.”
That’s a real cost. It’s just not on any spreadsheet.
The kitchenware retailer is still on Singtel Cloud. The site is faster in six of the eight markets they serve. The bill is lower. The team has learned to check disk queue depth and connection pool defaults and the peering topology of each target market before making architectural decisions. They test the worst path first now.
The best outcome of a cloud migration isn’t a lower price. It’s a set of measurements that tell you exactly what you traded to get there.
