Selected work
Two full cycles, and the projects inside them
Client names are withheld by convention. Sector and scale are accurate, and I am happy to be specific in conversation.
Built 2008 · private cloud 2012 · decommissioned June 2025
Building a data centre business, and closing it seventeen years later
I returned to Singapore as country head for managed services in 2008, after the global financial crisis ended the engagement I had spent five years building. Rather than rebuild the same kind of account, we started a business.
Fujitsu already had the systems division, the facility and my managed services department, which meant we could build and operate infrastructure at a cost base competitors buying the same pieces could not match. What was genuinely new was the commitment: funding a platform sized for several hundred virtual machines before the customers existed to fill it. We built the data centre in 2008 and 2009, then Fujitsu Singapore's first local private cloud on top of it around 2012.
That combination is what made the business grow. Japanese enterprises moving into Singapore — particularly those running SAP — wanted managed infrastructure rather than to operate their own, and the integrated cost base made the proposition competitive. The business became highly profitable, and Fujitsu subsequently moved me to a regional role to replicate the model in Malaysia, Thailand, Indonesia and the Philippines.
By the mid-2020s customers were moving steadily to public cloud and the economics that justified the original investment had reversed. I led the decommission of both the data centre and the private cloud platform, migrating the SAP estate off the original platform onto its successor before closing the facility I had opened.
Seventeen years from groundbreaking to decommission, both ends run by the same person — and the exit completed on schedule.
20 applications · 10 countries · 5 audits passed, no major findings
Consolidating a global insurer, and collapsing the audit to a single site
I was hired by Fujitsu in 2005 to lead the account of one of the largest US insurance groups, and the consolidation programme inside it: twenty disparate applications from around ten countries across Asia Pacific, EMEA and South America — Australia, Belgium, Chile, China, Hong Kong, India, Taiwan and the UK, with Japan and Poland partially hosted — regionalised into Singapore. The customer had no registered office here. The entire operation was run offsite by us, on a limited travel budget, with their executive owner in the United States.
Consolidation put the systems in one place. What made that worth doing was the control model around them: a full managed service under strict ITSM discipline, where even application code changes were deployed only by the Singapore team, through a three-environment path of development, staging and production. Nothing reached production by another route.
European regulation prohibiting the transfer of data out of the EU meant the UK, Belgium and Poland portions needed regulatory approval before anything could move. Compliance was built against named regimes in four jurisdictions on a framework of ITIL, COBIT and ISO 27000, with a quality management system constructed from the ground up to carry the evidence.
The engagement grew as the customer handed over harder problems. Global disaster recovery followed — clustering to their Mexico site and data replication to Beijing, chosen on a minimum distance requirement, with the DR facility built inside three months on top of the original scope. We replatformed the estate from Solaris to AIX to absorb utilisation the original architecture could no longer carry, delivered with IBM's specialists working alongside my team around the clock. Account revenue grew from roughly USD 1M to USD 25M, and the hosting contract was extended twice.
They were the toughest customer I have come across in forty years. That is not a complaint — it is the reason the account grew, because they kept handing us harder problems and we kept taking them.
In the wake of the 2008 crisis the customer reversed strategy and decentralised, which ended the engagement after five years. The premise had changed; the delivery had not.
Five internal and external audits between 2005 and 2008, passed with no major findings.
SGD 300K per month in unrecoverable cost · 8 enterprise customers · 9 months
Exiting a multi-tenant data centre before the meter ran out
The decommission above had to be executed, and this is what that took. Every month the facility stayed open carried around SGD 300K in running cost that could no longer be charged to customers — pure cost against the business. The estate spanned about 100 racks and 18 customers, eight of them substantial enterprise engagements with their own contracts, downtime windows and approval requirements.
The constraints made it harder than the scale suggests. Downtime windows conflicted: some customers would only move at weekends, others only mid-week. No IP changes were permitted, so applications and firewall rules had to come back up as if nothing had moved. Highly available pairs had to be split, run single-sided through the move, and rejoin cleanly on the other side.
Customers would not approve that on assurance alone. We proved the rejoin behaviour through Cisco simulation before asking for sign-off, and pre-staged identically configured loaner equipment to answer the question everyone asks: what if it fails after the move. Even the physical transit was planned with a second route, since a road accident inside a fixed window has no rollback. System and storage partners stood by throughout.
Around 50 racks relocated; the remainder were decommissioned or moved out by customers directly. All eight enterprise customers landed on schedule except one critical system that would not hold stable on a single leg. Rather than force the cutover, we ran it on both sides and moved it the following week, inside the contingency built into the plan.
The exit completed at the end of June, and the monthly cost stopped with it.
Termination notice issued · 530 open tickets · 100 days
Recovering an account that had already given notice
A managed services account in Thailand had issued notice to terminate. The relationship had deteriorated on every front: no regular meetings with the customer, no technology roadmap, a reactive delivery posture, 530 open tickets with unclear ownership, skills gaps on the team including English proficiency on a Thai-based account, and no dashboard giving the customer visibility of their own service.
I ran a structured 100-day recovery built on design thinking. It began with listening — to the delivery and sales leads, the account manager and the delivery team — before defining the as-is state honestly and grouping every issue raised into four categories. Two workshops converted that into a weekly improvement plan with a named owner against each item, tracked at weekly checkpoints and reported to both management and the customer as it went. The programme closed formally, signed off by sales, delivery, management and the customer, rather than quietly tapering off.
By day 100 the backlog had gone from 530 open tickets to 143 — 73% closed against a 60% target. Weekly internal and monthly customer meetings were running. English-speaking engineers were deployed and the skills gap addressed. Architecture work was underway, and an ITSM migration was scoped to give the customer real-time visibility.
The customer withdrew the termination and renewed the entire engagement.
Onboarding compressed 9 months → 3 · live across 228 stores
Building a retail service offering, not just delivering one
Retail store IT support in the region was conventional and reactive. Customers carried the assets, the procurement, the warehousing and the vendor management, while service desks handled high call volumes with limited knowledge support and no visibility for the customer. I led the design and enablement of an alternative: a subscription-based store support offering built on Fujitsu's ServiceNow-based platform.
The commercial construct came first. Rather than selling support hours, the model moved store IT to a per-store subscription with assets included — removing depreciation, procurement and inventory holding from the customer's balance sheet and turning unpredictable capex into a forecastable operating cost. The technology existed to make that economically viable for us to run.
Operationally it was built on ServiceNow modules: incident, problem and knowledge management, field service management with a mobile app for onsite engineers, asset and inventory management, a customer service portal and a real-time dashboard. Support was mapped along a maturity path from reactive through proactive to predictive, with analytics over machine, operational and business data driving spares optimisation, predictive maintenance and demand forecasting.
It went live with a global QSR chain across 228 stores in Thailand. Ticket lifecycle and turnaround times fell substantially. Parts availability, onsite engineer skills and ETA to site became trackable rather than assumed. Paperless job sign-off closed tickets at the point of completion, removing the delay where engineers returned to re-key completed work — which lifted SLA attainment without changing how the work itself was done.
Onboarding for new countries was cut from nine months to three, turning a bespoke engagement into a repeatable rollout.
We asked for hours. They gave us minutes. · standard approach rejected by client HQ
Redesigning a network cutover after the customer said no
The customer's network had to move as part of the data centre exit, but their head office in Japan rejected the standard approach outright. Fujitsu proposed a lift and shift from one facility to the other; Japan assessed it as too risky and requiring too much downtime, and would not approve it. We asked for hours of downtime. They gave us minutes.
The complexity was compounded by what the customer wanted to fold in. Rather than move and then modernise, they used the migration to refresh firewalls, decommission legacy devices, and replace their existing internet service with SD-WAN. Multiple site-to-site VPNs terminating on the DMZ firewalls had to be migrated ahead of the colocation network move.
This was colocation — we provided the facility, the customer ran their own network, and we had no operational role in it. The exit changed that. To move it we had to learn their design from the outside, take on the configuration, and lead the migration of an estate we had never managed.
What we built instead was migration in halves. WAN devices — MPLS, broadband and SD-WAN — had their HA pairs deliberately split, with only the secondary devices moved and HA re-formed across the two facilities. The same method was applied to the colocation estate: DMZ, main and remote access VPN firewalls, customer wireless and authentication servers. Services stayed live on the remaining leg throughout rather than taking an outage. Getting to an approved design took five rounds. We presented our model, the Singapore customer presented theirs, and Japan head office presented a third — each a genuinely different interpretation of how the migration should work, drawn out across forty to fifty slides. Three further rounds worked through the step-by-step flow until all three parties converged on a single runbook. Every step was then validated in lab and sandbox testing before any production change.
The cutover completed within the available windows with no service impact, and the firewall refresh, legacy decommission and SD-WAN migration were delivered alongside the move rather than deferred.