Moving a server room into AWS without a big-bang weekend
The IT head at the plant asked me which weekend we should pick for the cutover. He was moving a server room into AWS, and someone had told him it meant one brutal weekend. That is not actually the question. The question is whether you need a single cutover weekend at all. Most server rooms this size do not. His was a Pune auto-components firm, about 130 people, two racks in a room that doubled as the place where spare chairs went to retire. A file server, an ERP on an old SQL box, a domain controller, a UPS that beeped every few minutes like it had something to confess. He had been told the move to AWS meant a Friday-night-to-Monday-morning marathon, a war room, and a prayer. Bas, that is the version that scares people out of moving at all.
Why the big-bang weekend is the wrong default
A big-bang cutover moves everything at once. You freeze the business on Friday, copy the world, repoint everything, and hope it all comes up by Monday. When it works, you look like a hero. When one dependency you forgot refuses to resolve at 2 in the morning, you are rolling back a whole estate with a tired team and a Monday deadline you can no longer move.
The phased way is duller and far kinder to your weekend. You replicate each server into AWS while the original keeps running, test the copy quietly, then cut traffic to it one workload at a time. If a step goes wrong, you have moved one app, not forty. You roll back one thing. The plant keeps shipping. This is roughly the model AWS itself pushes through its Application Migration Service, which mirrors a live server into AWS in the background and lets you flip the switch on your own schedule.
Achha, there is a cost angle too, and it is the one the CFO actually cared about. A weekend war room is overtime, a consultant on standby, and a real chance of lost production if it slips. A six-week phased move is a few hours of attention spread across calm Tuesday afternoons. The second one is cheaper and you sleep through it.
200+ Indian businesses served. Response within 8 hours. No card, no contract, no sales call.
How we mapped the room before touching anything
Before any replication, we spent two days just listing what the room did. Not the servers, the jobs. The ERP that finance lived in. The shared drive that twelve years of drawings sat on. The domain controller. And a small, unloved tower in the corner running the attendance system and, it turned out, a floating licence service for two production-line tools. Nobody had written that tower down. It existed only in the memory of a technician who had left in 2022.
This mapping is the whole game. A server room is not a pile of boxes; it is a web of quiet dependencies. Move the ERP cleanly and it still falls over if the licence server it phones home to is now sitting in a different network with a firewall rule nobody wrote. We see this on almost every move. The documented systems behave. The undocumented one bites. If you want the cost side of this same exercise, our note on server consolidation for a Hosur manufacturer walks the same audit from the budget chair.
Moving a server room into AWS one workload at a time
We started with the file server, because it was the lowest-risk win. Replicate it into AWS, let it sync for a day, mount it for a pilot group of five people, watch for a week. No drama. Then the domain controller got a cloud sibling, so identity was not depending on one ageing box in a hot room. Then the ERP, the one that mattered, replicated and tested against a copy of the database while the live one kept running the plant. Matlab the business never saw the work happening.
The sequence was deliberate. Lowest blast radius first, identity second so everything after it had a stable foundation, the crown-jewel ERP only once we trusted the pattern. Each cutover was a Tuesday afternoon, not a weekend. We pointed the users at the AWS copy, kept the on-prem version warm for a week as a rollback, then retired it. We sized the instances against the AWS Well-Architected guidance rather than guessing, which kept the bill honest and the performance boring in the good way. People sell this as hyperscale magic. Hyperscale just means they have more racks than us, in more places, and in 2026 enough of them sit close to India that the old latency worry is mostly gone.
Here is the near-miss. The day we cut the ERP over, two line tools threw licence errors within the hour. The floating licence service on that forgotten tower could not reach the machines that had just moved networks. Forty minutes of a senior engineer and one firewall rule fixed it. In a big-bang weekend, that same error would have arrived at 1 in the morning alongside nine other fires, with no one fresh enough to trace it. Pakka, the phased approach is what turned a production stoppage into a footnote.
What the move actually cost, and what it saved
Karthik does not lead with the table, so here it is now that you have walked the reasoning. This is their estate, costed against keeping the on-prem room alive for another three-year cycle. Their numbers, not a vendor model.
| Three-year view | Keep the on-prem room | Phased move to AWS |
|---|---|---|
| Hardware refresh due | New servers and UPS, about 11 lakh | None. CapEx becomes monthly cost |
| Power and cooling for the room | Running cost every month | Removed |
| Cutover risk | One big weekend, lost-production exposure | Spread over Tuesdays, near zero |
| Disaster recovery | A second box they never bought | Built into the move |
| Monthly cloud bill | None, but you own every failure | Right-sized, watched, billed in INR |
The honest part: the AWS bill is a real monthly number, and it is the thing that surprises Indian SMBs the most. The vendor quotes you one figure and the bill arrives as another once data transfer and a few over-sized instances creep in. We have seen it happen, which is why we wrote up where an AWS bill quietly leaks for a Noida SaaS team. The fix is not to fear the cloud. It is to size it properly and read the bill every month, because a cloud move is a total cost of ownership question, not a sticker-price one. It also helps that you can be billed in rupees through AISPL instead of watching a dollar invoice swing with the exchange rate.
200+ Indian businesses served. Response within 8 hours.
What I would tell the next IT head
I came into this job leaning toward one well-planned weekend, because that is the move I had done for years and it feels decisive. Three calls and one near-miss later, I would phase it every single time for a room this size. The decisiveness of the big weekend is a feeling, not a result. The result is whether the plant shipped on Monday, and the phased move protects that better.
So map the room first, jobs not boxes, and hunt for the one server nobody wrote down. Move the boring things first. Keep the old version warm for a week after each cut. Read the bill. If you are also merging two companies or two tenants, the same parallel-run logic carries over to a tenant-to-tenant migration after an acquisition. And if you want a partner who has done this for Indian SMBs before, that is what AWS for Indian businesses is built around.
Key takeaways
- Skip the weekend war room. Replicate live, test quietly, cut over one workload at a time.
- Map jobs, not boxes. The undocumented licence or attendance server is what breaks a clean move.
- Sequence by blast radius: lowest-risk app first, identity next, the ERP last.
- Keep each on-prem server warm for a week as a one-click rollback before you retire it.
- The cloud bill is real. Right-size it, bill it in INR, and read it monthly so it never surprises a QBR.
FAQ
Do I really need a big-bang weekend to move my server room to AWS?
For most SMB estates, no. A phased move replicates each server into AWS while the original keeps running, so you cut over one workload at a time on a normal afternoon. You only consider a single cutover when systems are so tightly coupled they cannot run split for even a few days, which is rare below a few hundred users.
How long does a phased migration take for a small server room?
For two or three racks, plan four to eight weeks of calendar time, though the actual hands-on work is a few hours per workload. Most of the time is replication syncing in the background and a watch period after each cutover. The pace is set by how cautious you want to be, not by raw effort.
What goes wrong most often during a server move?
An undocumented dependency. A forgotten licence server, an attendance box, a scheduled job on a machine nobody logs into. The fix is a proper dependency audit before you replicate anything, which is where the phased method earns its keep because you find these one at a time instead of all at once at midnight.
Will my AWS bill be predictable?
It is predictable if you size instances to real load and watch data-transfer costs, and far less so if you lift everything at the same size it ran on-prem. Bill in INR through AISPL, right-size after the first month of real usage, and review the bill monthly. The cloud is not expensive by nature; an un-watched cloud is.
200+ Indian businesses served. 17+ years in IT. Reach us on WhatsApp at +91 91375 93228, 10 to 7 IST, or start above. Prefer a quote first? Response within 8 hours.
P.S. Sudeep here. We moved a Pune plant off its server room last quarter, and the IT head asked the same thing you are probably asking: is a slow phased move not just a longer version of the same risk? My answer was the one Karthik gave him. A long calm move where you can stop and roll back any Tuesday is a different animal from one tense weekend where stopping means the whole thing failed. Arre, slower is the safer kind of fast here.
