The Challenge
The organisation was running a large fleet of legacy ArcGIS servers hosting a wide variety of GIS services, backed by more than 2TB of unmanaged datasets. The platform sat on deprecated infrastructure that was difficult to maintain, carried significant security exposure, and cost approximately $10,000 per month to operate.
The core problem was not simply the cost. It was that the platform had reached a state where continued operation meant accepting compounding risk — unpatched infrastructure, no modern security controls, no automation, and datasets that had grown without structure or ownership. A like-for-like migration would have moved the problems, not resolved them. A clean decommmissioning was the only path that actually addressed the underlying technical debt.
What I Found
Working closely with service custodians, Cyber Security, and other major stakeholders, I conducted a full assessment of every service on the platform. What became clear early on was that the services did not share the same future. Treating them as a uniform migration target would have been a mistake.
Some services had no active user base and were candidates for proper retirement. Others were sound in concept but had been built on assumptions that no longer held — they needed to be redesigned before any migration made sense. And one service, the national basemap, had already been through a thorough design refresh and simply needed to be moved off the deprecated infrastructure.
The data landscape presented similar challenges, comprising a mix of raster and vector datasets that lacked effective governance. Inconsistent naming conventions, unclear ownership, and the absence of formal data classification were common, while the majority of datasets were hosted directly on the application servers, creating operational inefficiencies and increasing both security and resilience risks. Any new platform would have to address this before it could be built on.
How I Approached It
I applied a structured migration framework based on Retire, Redesign, and Replatform to assess every service, ensuring that no service was migrated by default. Each service was evaluated against clear business and technical criteria, with a well-defined rationale and target outcome guiding every migration decision.
Retire. Services with no active users, no identified business need, or where the function had been superseded were decommissioned. End users and custodians were informed through appropriate channels before decommissioning took effect, ensuring no silent removal of services that may have had undocumented dependencies.
Redesign. In collaboration with GIS subject matter experts, a roadmap and scope were defined for services that warranted a cloud-native rebuild. The unmanaged datasets were categorised into raster and vector types, and purpose-built RDS databases were designed for each category — improving query performance and end-user experience while giving the organisation genuine data ownership for the first time. Security was treated as a design constraint from the start, not a layer added at the end.
Replatform. The national basemap service had already been redesigned in a recent cycle. It did not need architectural rework — only a controlled transition off the deprecated infrastructure. This was handled as a focused replatforming exercise, with the primary goal being a clean cutover without service disruption.
The entire new platform was built in infrastructure as code, deployed through automated pipelines, and version-controlled in Bitbucket. The migration itself proceeded in structured phases: a proof-of-concept to validate the architecture; network foundation work (VPC, security groups, IAM, logging, DNS); data migration including conversion of legacy datasets to Cloud Optimised formats with encryption at rest and optimisation of the new databases; compute layer design (AMIs, Launch Templates, Auto Scaling Groups, a reverse proxy to protect back-end applications, ALB, WAF, and application-level logging); contingency controls (versioning, AWS Backup, alerting and metrics); and thorough testing across both non-production and production environments. At the end traffic was re-routed to the new platform with zero downtime.
What Changed
The new platform is a modern, self-contained environment built to current security and operational standards. Monthly operating costs dropped from approximately $10,000 to $5,700 — a reduction of nearly half — while the platform now handles twice the volume of requests that the legacy environment was receiving.
Beyond the cost and performance numbers, the organisation gained something more durable: a platform with genuine data governance, automated patching through the delivery pipeline, and infrastructure that can be maintained, audited, and evolved without the risk profile of the deprecated environment it replaced.
Lessons for Enterprise Cloud Platform Management
Classification before migration is not optional. The instinct in a large migration programme is to move fast. But moving services that should be retired, or migrating datasets without understanding what they are, creates technical debt in the new platform before it is even operational. The time spent classifying services and datasets at the outset repaid itself many times over.
The structured migration framework turns a complex programme into manageable decisions. With a large service catalogue, the question of what to do with each service can feel paralysing. Applying a consistent framework — retire, redesign, replatform — gave every stakeholder a shared vocabulary and gave every service a clear disposition. That clarity is what made the programme tractable.
Unmanaged data is a platform risk, not just a governance problem. Over 2TB of unstructured, unclassified datasets were not just difficult to migrate — they represented an ongoing operational liability. The decision to redesign the data layer, categorise datasets into raster and vector databases, and build proper ownership structures transformed that liability into a managed asset.
Security by design and cost efficiency are not in tension. The redesigned services were built with WAF, reverse proxies, encryption at rest, and IAM controls as foundational requirements. These did not add cost — in combination with right-sized infrastructure and IaC-driven automation, they were part of what brought the operating cost down. A platform designed with security constraints from the start tends to be better architected overall.
Infrastructure as Code is what makes a migration permanent. Migrating services manually would have produced a platform in a similar state to the one being decommissioned within a few years. Building everything in IaC and deploying through automated pipelines meant that patching, testing and change management became properties of the platform, not activities that depended on individual effort. That is the difference between a migration and an improvement.
Zero-downtime cutovers require planning that starts long before go-live. The traffic re-routing at the end of this migration was straightforward precisely because the contingency plans, versioning, backups, alerts and testing had been built into every preceding phase. Zero downtime is not achieved at cutover — it is the product of everything that happened before it.