The Migration Was the Easy Half

TL;DR: A Singapore health-tech company runs its core systems on two out-of-warranty servers in a converted store room, and nobody has tested a restore in two years. The board approves a move to cloud. The migration takes six weeks. The argument about who now owns patching, backup verification, cost review and the pager takes considerably longer — and it is that argument, not the migration, that decides whether the move was worth making.

Why the store-room server survives so long in Singapore health-tech

Singapore has a dense population of healthcare-technology and medical-device companies in exactly the awkward size band — roughly seventy to a hundred and ten people — where the infrastructure is genuinely load-bearing but there is no infrastructure team. These companies typically started as a product idea with a handful of engineers, won a first serious customer, and then grew on the back of that customer's expansion. Somewhere in the first two years, somebody bought a server. It was the right decision at the time: it was cheap, it was fast, and it was under the direct control of the one person who understood the product end to end.

What happens next is not negligence. It is the entirely rational behaviour of a company where every hour of engineering attention has a queue of customer-facing work in front of it. The server works. It has always worked. Replacing it produces no new feature, wins no new customer, and appears on no roadmap. So each year the decision is deferred, and each year the deferral is slightly more expensive than the last — not in cash, but in the number of things that now quietly depend on a box nobody has deliberately rebooted since it was commissioned.

The Singapore context sharpens this in two specific ways. First, commercial space is expensive, which means the "server room" is frequently not a server room at all — it is a converted store room, a cupboard off the pantry, or a corner of the office with a domestic split air-conditioning unit pointed at it. Second, Singapore-based health-tech companies sell regionally almost immediately. A company with ninety staff in one office may be serving customers in four or five markets, and those customers ask questions during procurement that the company's own infrastructure was never designed to answer.

That second point is usually what turns a deferred decision into a board-level one. The engineering team has been raising the hardware risk for two years without effect. Then a customer's procurement questionnaire asks where the data physically resides, what the recovery objective is, and when the last restore was tested — and suddenly the store-room server is a commercial problem rather than a technical one. This is the most common trigger we see, and it is worth naming plainly: the migration is rarely approved because the risk was finally understood internally. It is approved because somebody outside the company asked a question the company could not answer.

The scenario: what is actually on those two boxes

Consider an illustrative composite — not a named client, but a pattern assembled from the shape of engagements that recur in this segment. A Singapore healthcare-technology company, roughly ninety staff, sells a clinical workflow product to hospital groups and specialist clinics across several Asian markets. Its production platform already runs with a cloud provider; that part is modern and well understood. The problem is everything else.

In the store room sit two physical servers, both four years past warranty. The first runs a line-of-business application — the internal system that handles order management, device serial tracking, service scheduling and the customer records that feed the support team. It was deployed by a systems integrator that has since been acquired twice. The second runs a file share the whole company depends on: clinical documentation templates, regulatory submission working files, sales collateral, and a decade of project folders organised by a convention that only three people fully understand.

There is also a database. It sits on the first server, it backs the line-of-business application, and it is the single object in the building that nobody wants to touch. Its schema has been extended informally over six years. Two reports the leadership team relies on query it directly. The last person who genuinely understood its indexing left in 2023.

Backups run. This is the detail that makes the situation feel safer than it is. There is a backup job, it completes, and it writes a green tick to a dashboard somebody set up. What there is not is a tested restore. The last time anyone deliberately recovered a system from that backup and confirmed the result was usable was more than two years ago — and the person who did it did so as a one-off exercise, not as part of any standing process. The backup is therefore not a backup. It is a hypothesis about a backup.

Finally, there is one engineer. Not a bad engineer — usually a very good one — who built or inherited this environment and is the only person who knows why certain things are the way they are. This person is also the reason the environment has stayed up. They are also, in risk terms, the largest single item on the list, and everybody knows it, including them.

The real problems this produces

The individual issues are easy to list. What matters is that they compound: each one makes the others harder to fix, which is why environments like this tend to stay frozen until an external event forces movement.

• Hardware past warranty with no spare path. Four-year-old servers do not fail gracefully. When a disk, a controller or a power supply goes, the question is not "how long is the repair" but "does a replacement part for this generation still exist in Singapore this week." There is no spares strategy, because there was never a plan for this hardware to still be in service.
• Cooling and power that were never designed for the load. A domestic split unit maintains a comfortable room temperature; it does not maintain a server inlet temperature under sustained load, and it does not fail safely. Power is a single office circuit shared with whatever else happens to be plugged in nearby. A UPS may exist; whether its batteries still hold charge is usually unknown.
• Backups that run but have never been restored. Worth repeating, because it is the most under-priced risk in the entire scenario. Backup software reporting success tells you the job ran. It does not tell you the data is complete, the application will start, the database will mount, or the recovery will finish inside any timeframe the business would accept.
• Data-residency questions the sales team is now being asked. Where the data sits, who can access it, under what contractual terms, and what happens on termination — these arrive in customer procurement questionnaires and cannot be answered credibly by pointing at a store room. That is a commercial constraint on growth, not merely an IT concern.
• A single point of knowledge. One person understands the build. Documentation exists in the sense that some of it was written down at some point. If that engineer is on leave during an incident, the recovery time is not defined by the technology.
• No defined recovery objectives at all. Nobody has ever been asked how long the business can operate without the line-of-business application, or how much data loss would be acceptable. Without those two numbers, every design discussion is a matter of opinion rather than engineering.

Two of these deserve particular attention, because they are the ones most often mis-scoped during the migration itself. The untested-backup problem does not go away by moving to cloud — a cloud backup that has never been restored is exactly as unproven as an on-premises one. And the single-point-of-knowledge problem gets worse before it gets better, because during a migration that one engineer becomes even more load-bearing than usual.

The decision that actually matters: lift-and-shift or re-platform

Once a move is approved, the technical debate narrows quickly to one question, and it is worth being honest about the trade-off rather than presenting either answer as obviously correct.

Lift-and-shift takes the existing servers as they are and reproduces them as cloud virtual machines. It is faster, cheaper to execute, carries the least project risk, and can usually be done without touching the application at all. It also preserves the problem. The same undocumented build, the same informal schema, the same operating-system version, the same database nobody understands — now running somewhere else and billed monthly. Lift-and-shift removes the hardware risk, the cooling risk and the store room. It removes none of the operational risk.

Re-platforming changes the shape of the thing: a managed database service instead of a self-administered database, managed file services instead of a file server, identity and access handled by a platform rather than by local accounts. It takes longer, costs more to execute, and will surface problems the organisation has been successfully ignoring — usually in the form of an application dependency nobody documented. It also genuinely reduces the number of things the company has to operate afterwards.

The deciding factor is usually not the technology. It is how long the application will live. If the line-of-business application is scheduled for replacement in eighteen months, re-platforming it is close to a waste of money — lift it, remove the hardware risk, and spend the engineering effort on the replacement. If the application will still be in service in five years, lift-and-shift is a deferral with interest, and the re-platforming work will simply happen later under worse conditions and with fewer of the original people still around.

In practice, most environments of this shape end up split: the file share and the database get re-platformed onto managed services, because that is where the operational burden actually sits, while the line-of-business application is lifted as-is and scheduled for a decision later. That is a legitimate outcome rather than a compromise — provided it is a decision somebody made deliberately, and provided the "decide later" item has a date attached to it.

Brocent's perspective: a migration changes who owns which failure

"Move to cloud" gets described as a project, with a start date, an end date and a budget. That framing is what produces the disappointment that so often follows. A migration is not primarily a technical event. It is a change in the distribution of operational responsibility, and if that redistribution is not decided explicitly, it defaults to whoever was doing it before — which is the same overloaded engineer, now operating an environment they know less well than the one they replaced.

After cutover, four questions determine whether the move actually reduced risk.

• Who patches? Operating systems, application runtimes, database engines. The cloud provider patches the platform beneath your virtual machine. It does not patch what is inside it. This is the single most common misconception after a lift-and-shift, and it produces environments that are less well patched a year after migration than they were before.
• Who verifies that the backup restores? Not who configures the backup — who performs a restore, on a schedule, and confirms the recovered system is usable. If the answer is "nobody, but it's in the platform now", the untested-backup problem has been migrated along with the data.
• Who reviews the bill before it doubles? Cloud cost does not stay where it was on day one. Instances get resized upward during an incident and never resized back. Snapshots accumulate. Environments spun up for testing outlive their purpose. Without a named owner and a monthly review, the first unpleasant surprise usually lands somewhere between month four and month nine.
• Who gets paged? At 2am, for a system that is now somewhere else, when the person who understands it is uncontactable. An escalation path that terminates at one individual is not an escalation path.

A migration that does not answer those four questions has not reduced the company's risk. It has relocated it, added a monthly invoice, and removed the reassuring physical presence of a box you could at least walk over and look at.

What the operating model looks like when it is done properly

The alternative is not more technology. It is a defined set of standing responsibilities, agreed before cutover rather than discovered afterwards.

• Patching as a standing service, not an intention. Defined maintenance windows, a defined scope covering the operating system and the components inside the VM, and reporting that shows what was patched, what was deferred and why. Patch management is one of the thirteen items included at every service tier in Brocent's managed IT plans, alongside 24/7 monitoring and help desk — baseline, not an upsell.
• Backup with tested restores rather than green ticks. Brocent's cloud managed backup service is built around 24×7 backup job monitoring by the service command centre and regular recovery drills to verify backup integrity. The distinction between a backup that reports success and a backup that has been proven to restore is the entire point of the service. Backup and DR, including immutable backup, is likewise included at every plan tier.
• A backup topology chosen on purpose. The service defines four documented modes — local-full plus cloud for critical data, local-full plus cloud for everything, full bidirectional redundancy, and cloud-only. A company leaving a store room behind usually lands on the cloud-only model, but that should be a chosen position with a stated recovery objective, not the default that happened to occur.
• Cost governance with a named owner and a monthly cadence. Right-sizing reviews, orphaned-resource cleanup, and monthly cost and performance reporting. Brocent's managed cloud services practice targets a 20–40% reduction in cloud waste through right-sizing, which is only achievable if somebody is actually looking at the bill on a schedule.
• An escalation path that does not end at one person. Tiered support with defined response commitments, so the in-house engineer becomes the person who understands the business context rather than the person who must personally be awake for every incident.

On the platform question itself, the honest answer is that it depends on where the customers are. Brocent's cloud solutions practice covers Azure and Microsoft 365, AWS, Alicloud and Tencent Cloud — the last two mattering specifically for companies whose growth path includes China Mainland, where ICP-compliant hosting is a practical constraint rather than a preference. For a Singapore company selling across Southeast Asia the platform decision is usually straightforward; for one whose roadmap includes China, it is worth settling early rather than migrating twice.

Three ways to run this, compared honestly

• Stay on-premises. Known cost, no migration project, complete control. Against that: ageing hardware with no spare path, a cooling and power environment never designed for the load, a single point of knowledge, and a data-residency answer that will keep costing you deals. Defensible for a company whose customers do not ask infrastructure questions — and an increasingly rare position in health-tech.
• DIY cloud. Maximum flexibility, no third-party dependency, full control of the design. Against that: every operational task that used to be shared or quietly ignored is now explicitly yours — patching, backup verification, cost review, monitoring, out-of-hours escalation. For a ninety-person company with one infrastructure engineer, this is the option that most often produces a technically successful migration with a worse operational outcome than the store room it replaced.
• Managed cloud (the Brocent model). Migration planning and execution, plus a defined post-cutover operating model: patching and monitoring as standing services included at every plan tier, backup with scheduled recovery drills rather than dashboard ticks, monthly cost and performance reporting, and a tiered escalation path with named owners. Against that: it is a commercial relationship with a monthly cost, and it requires the company to define its recovery objectives rather than leave them implicit — which is work, and which is also rather the point.

Where to go from here

If the two servers in your store room are past warranty and your last tested restore predates your current head of engineering, the useful next step is not a migration proposal. It is an honest inventory: what runs on each box, what depends on it, what the business would tolerate losing, and how long it could operate without each system. Those answers determine the design. Without them, any migration plan is a guess with a diagram attached.

Brocent has been delivering managed IT and cloud work across Asia since 2007, with headquarters in Singapore since 2021, and has run this specific pattern before — including cloud architecture design and long-term managed infrastructure support for a global healthcare-technology firm through an acquisition, spanning Azure and Microsoft 365 E5, Intune, identity and a regional endpoint refresh. You can see the plan structure and what is included at each tier on managed IT support, or get in touch to talk through what is actually sitting in your store room.

Frequently asked questions

Should we lift-and-shift or re-platform?

Decide it on the expected remaining life of the application, not on the technology. If the system will be replaced within roughly eighteen months, lift-and-shift: remove the hardware risk cheaply and put the engineering effort into the replacement. If it will still be running in five years, re-platform the components that carry the operational burden — typically the database and the file share — because otherwise you will do this work later, under time pressure, with fewer of the original people still available. A split outcome, where one system is lifted and another re-platformed, is common and entirely legitimate.

Where will our data physically sit?

That is a design decision you make, not something the migration decides for you, and it should be settled before any workload moves. Every major platform lets you pin workloads to specific regions, and Singapore is well served by all of them. What matters is that the answer is documented, that it matches what your sales team is telling customers in procurement questionnaires, and that it accounts for where your backups and any replicas live — those frequently sit in a different region from the primary and are just as frequently overlooked. Whether a given arrangement satisfies a particular regulatory obligation is a question for your own legal counsel and the relevant regulator; we can describe where data sits and how access is controlled, but that determination is not ours to make.

Who owns patching after we move?

Whoever you write down as the owner. The cloud provider patches the platform beneath your virtual machine; the operating system inside it and everything running on it remain your responsibility unless you have contracted that to somebody. Under a managed arrangement, patch management is one of the items included at every Brocent plan tier, with defined maintenance windows and reporting on what was applied and what was deferred. Under a DIY arrangement it belongs to your engineer, and it should be scheduled and resourced explicitly rather than assumed.

How do we know a backup actually works?

By restoring it on a schedule and confirming the result is usable. There is no other method. A completed backup job proves the job ran; it proves nothing about whether the application starts, the database mounts, or the recovery finishes within a time the business would accept. Brocent's cloud managed backup includes regular recovery drills for exactly this reason, alongside 24×7 job monitoring. If you take one thing from this article, make it this: schedule a test restore of your most important system this quarter, whatever else you decide about cloud.

Will cloud cost more than the servers we already own?

Compared against the purchase price of hardware you have already paid for, usually yes — but that comparison is not a useful one. The comparison that matters includes the replacement cost of the hardware you are about to have to buy, the cost of the downtime you are currently exposed to, and the commercial cost of the deals your data-residency answer is affecting. What is true is that cloud cost drifts upward without governance: instances get resized during incidents and never resized back, snapshots accumulate, test environments outlive their purpose. Right-sizing and monthly cost review are what keep the number honest — Brocent's managed cloud practice targets a 20–40% reduction in cloud waste through exactly that discipline.

What happens to our in-house engineer's role?

In our experience this is the question people actually care about, and the honest answer is that the role usually improves. What disappears is the undifferentiated operational load — patching, watching backup dashboards, being the only person who can respond at 2am. What remains and grows is the part that requires knowing your business: how the product works, what customers need, which internal system matters most in which week, and how to make good architectural decisions. A managed arrangement should make your engineer more effective and less irreplaceable, in that order.

How long does a migration like this take?

For an environment of this shape — two servers, a line-of-business application, a file share and a database — a well-planned migration is typically measured in weeks rather than months, and comparable Microsoft 365 and cloud migration projects Brocent runs are usually two to six weeks from needs analysis to go-live. But the timeline that matters is not the cutover. It is how long it takes to agree the operating model afterwards: patching ownership, restore-testing cadence, cost review, escalation. Companies that settle those before cutover finish the project once. Companies that defer them tend to discover, several months later, that they moved the risk rather than reducing it.