Most migrations don't fail on the technology. They fail on scope creep, half-decided cutovers, and the quiet assumption that the plan will survive contact with production.
This is the story of one that worked. Four weeks, two applications, a set of databases, and every byte of user data and file storage — moved off a struggling VPS and onto AWS for Siyakha Consulting. By the end, the platform was handling eight times more concurrent users than before, and the monthly hosting bill was 40% lower than the VPS one.
1. The starting point
Siyakha's platform lived on a VPS. For a small user base, that setup is hard to argue with.
Then the user base grew which led to more activity and more load that the infrastructure could not handle. The traditional fix — a bigger VPS — meant paying for hardware that sat idle between the peaks.
The platform worked. It just required more resources to scale which meant a bigger bill.
Before configuring a single AWS resource, the team secured AWS credits. These credits fully covered the migration process and several months of subsequent hosting for Siyakha Consulting. This financial buffer eliminated a common migration pain point: no double hosting costs.
2. Why four weeks?
Four weeks is the outcome of scoping the work honestly, and it is only realistic when three things are true:
- The applications can be containerised without a rewrite. If week one reveals the app needs restructuring first, the timeline changes.
- The data can tolerate a replication-based migration: we set up the new databases, replicate continuously, and cut over once the data has caught up.
- Someone on the client side can make decisions quickly. Most multi-month migrations aren't always slow because of engineering. They're sometimes slow because decisions need to go through several review processes before approval.
If those three hold, four weeks is genuinely enough. If they don't, better to find out in week one than in week three.
3. Week 1 — The Free Assessment
In Week one we assessed every application and identified the dependencies.
In parallel, we configured the VPC, subnets across availability zones, security groups and IAM. Nothing deployed yet. The platform is still running on the VPS.
By the end of week one we had listed all the dependencies, and presented a cutover plan.
4. Week 2 — Move the data
Once the cutover plan is approved, with the VPC in place, we set up the new databases and started replication from the VPS. The old environment kept serving users the whole time. The data moves without affecting production.
User data and file storage is also migrated. The point of week two is for the new environment to quietly catch up with the old one.
5. Week 3 — Modernise the applications
Week three is where migration turns into modernisation. We containerised all applications without modifying any application code.
CI/CD pipelines replaced any manual deployment processes.
We also load tested the new environment. The 8x more concurrent users isn't just a projection, it is the load the platform handled comfortably in testing before we moved a single real user onto it.
6. Week 4 — Cut over, harden, baseline
In week 4, the DNS records were updated, and we reviewed the platform's security.
The last item of week four is one most migrations skip entirely — establishing a cost baseline. A migrated environment is a new environment, and new environments start oversized. Using Sunbird Insyte, we established the baseline: scanning the cloud environment, flagging what was over-provisioned, and generating a rightsizing list to work through.
More on that below.
7. The results
- Four weeks to migrate from VPS to AWS, with the old VPS serving users until the final week.
- 40% lower monthly hosting costs than the VPS bill.
- 8x the concurrent users the platform could support comfortably.
8. The part most migrations skip
A migration moves your costs. It doesn't automatically reduce them. If you lift-and-shift onto oversized instances and never look at the bill again, you have traded a VPS problem for a cloud problem.
Establishing a baseline straight after cutover is what makes the saving stick. Sunbird Insyte provided a clear picture of what everything cost and why.
9. Get the full case study
Download the full four-week Siyakha Consulting migration as a PDF.
Need Help With Your Infrastructure?
Sunbird Analytics can help migrate and modernise your workloads on AWS, keep them secure, compliant and cost-optimised..