Insights

Planning PRISMA’s Cloud Migration

Written by Tobias Troeger | Jun 17, 2020 7:30:00 AM

When companies start thinking about cloud migration, it can feel overwhelming. Concerns about data loss, privacy, cyber threats, or internet reliability all lead to a healthy dose of caution. But the benefits are undeniable—greater performance, increased customer value, and significantly lower IT maintenance costs.

My team led PRISMA’s move to the cloud, and in this article, I’ll walk you through how we planned it, how we minimized risks, and why every company’s migration journey looks a little different.

My Role in the Migration

The idea to move to the cloud initially came from me, so I started out as a stakeholder and gradually became an active team member. My main responsibility was identifying any organizational roadblocks and creating space for the team to focus. During the migration, I often acted as the company’s voice—making quick, high-impact decisions to keep the schedule on track. After the move, I used my technical background to identify any leftover issues from the previous setup.

From On-Premises to the Cloud

Previously, our system was built on a single instance storage (SIS), meaning one shared copy of content across users and computers. While there was redundancy between two data centers, everything ran on this central setup.

When we migrated to the cloud, we used a “lift and shift” approach—moving everything over with minimal changes. Then, we began breaking the system into smaller pieces so we could deploy, test, and maintain features independently. That was a game-changer.

Why Cloud, Why Now?

Our shift to agile software development—releasing updates every few weeks instead of every six months—highlighted a disconnect. We were fast on the development side, but slow on infrastructure due to procurement, contract negotiations, and vendor delays. We needed to align both worlds. Cloud services offered us that agility.

We quickly developed a proof of concept with one of the major providers and, after finding no major roadblocks, decided to go for it.

Laying the Groundwork

We kicked things off with a “storming” phase—bringing together our Dev and Ops teams, plus application managers, to define the delivery approach. We chose a KANBAN process with a central backlog for full transparency.

One of the first and most important steps was creating a unified team. Previously, our teams worked in silos. We also made sure to include our ops staff early, as their historical knowledge was crucial.

We ranked our goals by priority to avoid conflicting messages from leadership—choosing a clear, consistent focus from the start.

Choosing AWS

Amazon Web Services stood out because of their top rankings in Gartner reports, high-level certifications, European data centers, and broad service offerings. We also opted for an “all-in” cloud approach—avoiding hybrid solutions. This allowed us to simplify operations, reduce vendor dependencies, and run one efficient system.

A full year before the migration, we verified AWS's infrastructure, reviewed certifications, and held in-depth talks with their key account managers.

Preparing Our Clients

We practiced dry runs repeatedly to make the migration as smooth as possible. A few months before the switch, we let clients connect early to the new endpoints. When the actual migration night came, they barely noticed a change.

Prioritizing Goals

We prioritized based on what caused the most friction in our work—not just costs, but process pain points. For example, we asked, “What takes the most time right now, and how can we fix that?” These decisions were made by the team, not just management, to reflect the real experience on the ground.

Key Partners

BTC, our long-standing IT provider, played a critical role. They hosted our legacy system and provided essential infrastructure expertise. We essentially became one team during the project—and got the chance to build strong connections with many new people along the way.

Business Continuity and Disaster Recovery

One major advantage of moving to the cloud was the chance to upgrade our disaster recovery plan. Previously, both backup centers were in the same city—if that city went down, we’d lose both. Now, we’re set up in both Frankfurt and Ireland. If Frankfurt fails, Ireland takes over—and gas transport continues uninterrupted. We can restore everything within three hours. That’s a huge improvement.

The Bigger Picture

As a platform critical to gas capacity trading, PRISMA is essential infrastructure. If we go offline, TSOs across Europe would need to revert to their own systems—creating serious disruption.

Security and reliability are our top priorities. Early on, we focused on getting the basics right: access control, compliance, and risk management. We never wanted speed to come at the expense of safety.

That mindset is part of PRISMA’s DNA—move carefully, listen to every voice on the team, and never compromise on what matters most.

In Part 2 of this interview series, coming next month, we’ll speak with Dominik about the lessons learned one year after PRISMA’s cloud migration.