This article is based on a case study originally published by ZDNet, featuring Rob Howe, IT director at Guinness World Records (GWR).
The Case for Moving Slowly Before Moving to the Cloud
Cloud migration is frequently treated as an urgent, all-or-nothing transformation project. Rob Howe, IT director at Guinness World Records (GWR), offers a markedly different perspective: tread carefully, understand your workloads thoroughly, and only then decide how cloud infrastructure can serve your business goals.
“Cherry pick the key elements — understand the changes you need to make to the infrastructure, and the behaviour of software, when you’re moving over,” says Howe. “Be aware of the differences and account for them. Not all systems will move easily. The cloud should not be viewed as a one-size-fits-all solution to your business challenges.”
Start by Listening, Not Planning
When Howe joined GWR in May 2012, he spent his first six months simply sitting with teams across the business to understand how they worked — without altering or even planning changes to IT systems. This deliberate observation period gave him a clear picture of actual day-to-day workloads before any transformation decisions were made.
“You can’t implement changes without understanding the day-to-day workloads of people across the business,” he explains. “If you’re not involved in the operational side of the organisation, then you’re probably going to fall over something further down the line.”
This approach directly informs one of the most common failure modes in cloud projects: IT teams that design migration plans in isolation, without accounting for how the business actually uses its systems.
A Staged Digital Transformation
Rather than attempting a big-bang migration, Howe led a phased digital transformation that built incrementally on solid foundations. Key milestones included:
- Implementation of a records management platform from SDL
- Deployment of a digital asset management system from Asset Bank
- Adoption of Salesforce CRM technology
- Finally, migration of business-critical IT architecture to Amazon Web Services (AWS), managed by partner Ensono
Cloud migration was treated as the final stage of transformation, not the starting point. That sequencing matters: GWR first consolidated its data management and customer relationship tooling before moving core infrastructure to a public cloud platform.
Managing a Multi-Partner Migration
One of the most underestimated challenges in cloud migration is vendor coordination. GWR’s transition to AWS involved Ensono as the primary partner, plus eight additional providers — including SDL and Asset Bank — all of whom needed to ensure their platforms functioned effectively on AWS.
“Some of these providers have to redesign their platforms to work more effectively on AWS,” says Howe. Managing that coordination across nine vendors simultaneously was, in his assessment, the primary operational challenge of the entire project.
Howe’s advice for other CIOs in this position is direct: find a trusted primary partner and let them lead the infrastructure conversation. In GWR’s case, Ensono — rather than advocating for its own private cloud — recommended migrating to AWS. That willingness to recommend the best-fit solution, rather than the most commercially convenient one, was a key factor in the partnership’s success.
Why Lift-and-Shift Fails
Howe is unambiguous on one point: simply replicating existing on-premises infrastructure in the cloud is a recipe for problems. During pre-migration research, he observed that organisations struggling most with their cloud transitions were those that had taken their existing infrastructure, replicated it as-is, and discovered a host of unexpected issues.
“Don’t just lift and shift — as part of the research I did prior to the move, I found all the people who were struggling had moved to the cloud by just literally taking their existing infrastructure, replicated it and found a bunch of problems.”
— Rob Howe, IT Director, Guinness World Records
A genuine cloud migration requires rethinking how software behaves in an on-demand environment: how it scales, how it fails, how it is monitored and how costs are attributed. Infrastructure that was designed for predictable on-premises conditions may need significant re-architecting before it is cloud-ready.
Real-World Scalability: Handling Unpredictable Traffic Spikes
GWR’s business model has shifted significantly. Historically, the organisation had predictable traffic peaks: the annual book launch each September and Guinness World Records Day in November. As GWR evolved from a publishing business toward a digital media and consultancy model, traffic patterns became far less predictable.
The value of cloud-native auto-scaling was demonstrated almost immediately after go-live. On the first day the new AWS infrastructure was live, a press release about a world record for the largest unlimited wave surfed by a woman went viral in the surfing community. Within hours, GWR’s web traffic reached four times its normal daily volume — a spike the new infrastructure handled comfortably using AWS auto-scaling, without manual intervention or emergency capacity provisioning.
This kind of elastic capacity is particularly valuable for media and content organisations, where a single viral moment can dwarf normal traffic volumes within minutes.
Operational and Financial Benefits
Beyond raw scalability, Howe identifies several operational improvements resulting from the cloud migration:
- Higher service levels across public-facing websites
- Ephemeral project environments: teams can spin up isolated infrastructure for a finite multimedia project and decommission it when complete, avoiding permanent capital expenditure
- Greater cost transparency: cloud billing models make it easier to understand and attribute infrastructure costs
- Improved team agility: IT can focus attention strategically rather than managing routine infrastructure capacity
The ability to provision temporary, isolated environments is particularly relevant for DevOps teams running short-lived feature branches, load tests, or client-specific demos — use cases where permanent infrastructure investment makes no financial sense.
What Comes After Migration: Microservices and Edge Computing
Howe views the AWS migration not as the destination, but as the foundation for continued evolution. His stated next steps at the time of the original interview were:
- Converting GWR’s API layer to a microservices architecture
- Evaluating which data should be distributed to edge locations to improve performance and reduce latency for global users
This progression — from monolithic on-premises infrastructure to public cloud IaaS, then toward microservices and edge distribution — reflects a broadly recognised maturity path for cloud-native engineering teams.
Industry Context: Vendors Embracing Hyperscale Platforms
GWR’s experience aligns with a broader market shift noted by Gregor Petri, research vice president at Gartner. Rather than competing head-on with hyperscale cloud providers such as AWS, Microsoft Azure and Google Cloud Platform, an increasing number of managed service vendors are opting to run their services on top of these platforms — combining their specialist expertise with the scale and reliability of hyperscale infrastructure.
This is precisely the model Ensono adopted with GWR: rather than advocating for its own private cloud environment, it guided the customer toward the platform most likely to meet long-term business needs. CIOs evaluating managed service partners should look for this kind of vendor neutrality as a signal of trustworthiness.
Key Takeaways for CIOs and DevOps Leaders
GWR’s cloud journey surfaces several principles that apply broadly to organisations of any size planning a cloud migration:
- Understand before you act. Spend time learning how the business actually operates before designing any migration strategy.
- Stage your transformation. Consolidate critical business systems first; treat cloud migration as a later step, not the starting point.
- Choose partners carefully. A good partner will recommend the best solution for your situation — not just the one that benefits them most.
- Don’t lift and shift. Replicating on-premises architecture in the cloud preserves its problems while adding new ones. Design for cloud-native behaviour from the outset.
- Plan for the unexpected. Unpredictable traffic spikes, viral moments and business model changes are reasons to embrace elastic cloud infrastructure, not reasons to delay migration.
- Stay ahead of the business. IT’s role is to enable business agility, not to react to it after the fact. Use the cloud’s flexibility to deliver faster, more responsive services.
Cloud migration is not a one-time project. Done well, it creates a platform from which teams can continuously improve services, adopt new architectural patterns, and respond to business change without the friction of fixed infrastructure constraints.
Original reporting by ZDNet. Full interview available at zdnet.com.