Planning PRISMA’s cloud migration: A step-by-step approach
Enterprise Architect
As a business grows, its IT infrastructure must grow with it. And nowadays a requirement for almost every company wanting to scale up is to move its data, applications and other elements to a digital cloud environment. In the first of a three-part series, Tobias Troeger, PRISMA’s Head of Application Management, discusses the roadmap that enabled our successful passage to the cloud.
For most businesses, the thought of moving to the cloud is a daunting one. Concerns over data loss, privacy risks, susceptibility to external attack, internet connectivity, and other potential hazards all play into the sense that a high degree of caution should be applied when it comes to planning how and when your company makes the move.
But the incentives are clear. The measurable upsides to a successful transition to the cloud – such as optimising your product and service performance, delivering more value to customers, and spending less on IT maintenance – represent a huge opportunity for modernisation and long-term growth.
At the vanguard of PRISMA’S cloud migration has been Tobias´ team. We sat down with him to learn more about the steps taken to plan and prepare for the move, how this helped to minimise complications and ensure that security and energy regulation were maintained at all times, and why every company’s cloud migration is unique.
Tobias, can you start by explaining your role at PRISMA specifically in relation to the cloud migration?
“Having had the original idea, I would probably describe myself initially as a stakeholder who then evolved into a team member. My core role within the project was to forecast any organisational impediments to what we wanted to achieve, and to create space for the team to focus on this project without too many distractions. During the migration I also had to be a kind of voice for the whole company. So if there was a tough or quick decision to make, I ensured this took minutes rather than hours, which would have jeopardised our schedule. Then post-migration, I was also responsible for using my technical experience to identify any legacy issues that may have crept into our new system.”
For those perhaps unfamiliar, are you able go into any detail about the difference between a cloud-based system and the previous system used by PRISMA?
“The previous system we used was built so that everything application-wise was on one single instance storage [SIS], which essentially means one copy of content is kept and shared between multiple users or computers. Within that there was some redundancy into two data centres, so that if one failed, the other one was available – but basically the whole application was on SIS.
Then when we moved to the cloud we broke it up into different pieces, and we did that because we wanted to be able to deploy smaller things and deliver it in smaller chunks so that we don't need to consider all tests and changes for the whole system, but rather do it for a small portion with a lowered risk of having to deploy it.
The way we did this is known as the "lift and shift” approach, which means migrating your application and associated data to the cloud with minimal or no changes, so that you’re not changing everything at the same point in time. Then in the second step, we split it up into smaller pieces.”
Taking us back to the initial choice to migrate to the cloud, was there a specific event that precipitated this decision, or was it simply part of the natural evolution of the company?
“I would say it was both. Before we actually moved into the cloud, we also changed our paradigm for how we develop software. We moved from an aesthetic-oriented waterfall approach with one release every six months to an agile approach where we delivered new software every couple of weeks. We somehow fell in love with this approach, but when we actually compared it against how we built new infrastructure for our platform, we saw that the two worlds were completely misaligned.
So on the one hand, we were moving very quickly with our software development, but on the other much slower with our infrastructure due to the added need to purchase things, write long contracts, negotiate with vendors, and so on. When this difference became apparent, we started looking for approaches that would enable us to speed up the infrastructure side, and we alighted on the idea of cloud services. We quickly created a Proof of Concept to assess whether it would be viable for us to move to one of the major cloud providers, and after failing to turn up any major road blockers we made our decision.”
And what were the initial steps undertaken to launch the project?
“We began with a ‘storming’ phase, which involved bringing together our Dev and Ops teams, along with our application managers, to decide on the delivery procedure. At this early point, we decided on a KANBAN procedure that would include a backlog – a central point where we’d put everything.
What we knew very early on was the importance of creating a common, unified team. Until then, all of our teams were working more or less in silos, so we needed to bring them together into one. Another important point step was actively pulling in the operational staff, who had historical knowledge of the platform that would be critical to what we were trying to achieve.
We also decided to rank our targets based on priorities in order to avoid a situation whereby management were coming to us with differing requests for what we should focus on, whether it be cost saving, speed, etc. So we made a very clear decision on an order of priorities.”
Could you talk us through the decision to use Amazon Web Services?
“Firstly, AWS are the market leader in Gartner [the world's leading research and advisory company] studies who provide a high level of certification and security, as well as several data centres across Europe. These, along with the wide range of services they offer, were key to our decision.
This was also tied in with our choice to adopt an ‘all-in’, rather than hybrid, approach. Not only did this give us independence from integrated vendors and an ability to perform IT operations internally, but also enables us to maintain only one operating model and process, and in doing so enhancing efficiency and cost-savings.
However, the decision to use AWS was highly contingent on the viability of their critical infrastructure and we actually checked this a whole year before starting the migration. We had direct contact with them, checking their certificates and also engaging in intensive discussions with their key account.”
What about preparing clients for the move – how were they impacted?
“First and foremost, we prepared by performing endless dry runs, just practicing again and again how the migration could work in a way that would be as seamless an experience as possible for our clients. Then, one or two months before the actual migration, we undertook more detailed planning and decided to allow our clients to switch a little bit early onto the new end points. And so when it came to the night of migration we were able to ensure they weren’t actually affected at all.”
You mentioned prioritising targets – are you able to elaborate on how you did this?
“The way we prioritised our targets was to consider the question, ‘what are our biggest stress-points in our way of working right now and how would we like things to change in the future?’ For example, of course it matters what a company pays for its infrastructure, but perhaps this isn’t as important as all of the process hurdles faced in order to deploy that infrastructure. And these decisions were made not from a management perspective but rather a team and engineer perspective.”
Were there any other partners or affiliates who played a role in the planning process that come to mind?
“One would definitely be BTC, who are our long-term IT provider and have supported us since PRISMA was founded. We joined forces with them to move our application. They host our legacy system and thanks to their knowledge on the infrastructure side had an important role in the lead up to the migration, as well as bringing in developers to the team. In fact we ended up effectively forming a mixed team with them, so it was also a chance to work with and get to know a lot of new people. They certainly played a very active part in the whole project.”
What measures did you take to ensure business continuity ahead of the migration?
“One major advantage of moving to the cloud was that it actually enabled us to extend our disaster recovery plan. Beforehand, our two data centres where redundancy – i.e. backup power – is stored were both in one city, so if that entire city went down, we’d lose both centres. By moving to the cloud we were able to have one data centre in Ireland and another Frankfurt, so if Frankfurt should fail, we can swing to Ireland and the gas transportation can continue unhindered. We also established procedures and processes that would allow us to restore within three hours at a location. And that's a big difference compared with before and has gone some way to bolstering our business continuity contingencies.”
That brings us neatly onto my final question, Tobias. It would be great to hear your thoughts on PRISMA's role within the gas industry and how this influenced your cloud migration planning?
“We are a critical infrastructure for the gas capacity trading. Quite simply, if we aren’t operational, every TSO in Europe would need to go back to its own system, which would create a big hurdle for all users. With this in mind, it is essential that we prioritise security and reliability.
With regard to our cloud migration, one of the major concerns we had in the ramp up was whether we have an effective authorisation concept. Do we check compliance regularly enough, for example? So we invested quite a bit of time in this initial phase to make sure that these basic prerequisites were never overlooked in the pursuit of increased speed or cost cutting.
Ultimately it is a part of the DNA of PRISMA to put security first and never move too quickly. And essential to maintaining these standards is the fact that everybody at the company has a voice and is able to raise their concerns. Overall I would say that when it comes to a process as complex and important as cloud migration, having a team that feels empowered in this way is never more important.”
In Part 2 of this interview series to be published next month, we’ll speak to Dominik about the lessons learned one year after PRISMA’s cloud migration.