Let’s say it’s your first week on the job as a VP of Infrastructure at an insurance company. The industry is changing rapidly—mostly spurred on by customers who next expect cloud-native applications as part of their user experience—but when you look around you find that your company’s technology stack hasn’t changed alongside it. Your goal is to provide infrastructure that powers high-performing applications and processes that high-performing teams can rely on, and to do so on a budget. With the current stack, neither of those aims is feasible.
On a high level, your next move is pretty clear: you need to migrate some combination of infrastructure, platforms, applications, or processes to the cloud. This might mean transitioning services that are currently residing on-premise, or moving away from an unwieldy private cloud deployment towards something like Azure or AWS—but whatever the situation, you need to be able to position IT and operations for future cost savings without making a huge upfront investment.
This might sound like exactly what the cloud was designed for, but the days of automatic cost savings in the cloud are over. Whether it’s because you don’t have the expertise to properly configure your reserve instances, or because you didn’t account for the costs of ongoing maintenance, or any of a number of other reasons, it’s all too easy to wind up in a situation where achieving positive ROI is a longshot. It helps to get as much right as possible from the get-go, but that too is easier said than done.
To wit, a whopping 73% of IT decision-makers in one poll say that their #1 cloud priority for this year is actually OPTIMIZING existing deployments. Read that number again. Nearly ¾ of those surveyed, and the pool included CIOs, CTOs, DevOps managers, and CISOs say that they need to rework their cloud tools because something about them is problematic.
The upshot here is that successful modernization depends on your ability to manage the whole cloud lifecycle, from migration and configuration to management to long-term support. We’ll give a high level overview of each puzzle piece over the course the next 1,700 or so words—and the first trick to staving off cloud disasters to determine, for each phase or step, whether you have the in-house experience and capacity to get it right the first time.
Stay with us here, as this first suggestion may sound self-evident at first. You might be shocked to discover that a good number of cloud rollouts go belly up for the simple reason that a requirement was missed or because someone failed to ask receiving how they actually use the ERP (substitute receiving and ERP for any department and whatever tool they spend 90% of their day using).
Gartner has laid out a clear outline for you when it comes time to begin planning your cloud project, and it’s called The Five R’s of Cloud Migration:
And don’t forget that planning includes assessing your current capacity and available resources. If you find that your teams are maxed out, don’t have the skills necessary for success, or some combination thereof, this is when you would look for a service provider to partner with. You or your team might have cloud experience in a specific area, but you have to make sure there’s coverage of every stage that applies to your situation. Bringing in the expertise at this early stage is how you can avoid your migration becoming a statistic.
A successful cloud migration will look a lot like other IT projects when you look in the rearview mirror. There are general steps for pretty much any project that involves technology, steps that, when followed, lead to things staying on course and reaching the finish line intact. In broad strokes these steps are:
By taking small bites like this, you enable your team to move more iteratively and that allows time for reflection on each completed step. By taking a step back from the project and looking at it from the 10,000 ft level, you’re more likely to catch issues, missing data, or other factors that stand to throw a monkey wrench into the works. Before it happens.
It’s the early stages, assessment and planning specifically, when you should be looking at your existing systems and how everything interacts in order to get a full picture of what is ripe for migration and what may need to stay put for the time being so as not to be overly disruptive. Better yet, take this opportunity to deploy an entirely new app into your ecosystem, one that can be deployed as cloud-native from the start. Now everyone can get used to this new tool in its native environment, gaining knowledge of how the cloud will be integrated into their workflow in the future. If your internal users or application development team are clear about their needs, you can scope up the most likely performance pitfalls on the one hand and opportunities for cost savings on the other from the outset.
Ever gone looking for your car, only to discover your partner didn’t park it in your usual spot when they got home last night? Now you’re wandering randomly around the lot clicking Unlock and watching for the flashing headlights. Now imagine coming into work after a long weekend, and finding that the software you spend the majority of your time in no longer works. You click your usual desktop shortcut and...nothing. You run to the team lead in a panic only to be told that tool was migrated to the cloud over the weekend and there’s an entirely new set of procedures you’ll need to get up to speed on immediately in order to do your job.
Don’t be the cause of office panic.
Part of your cloud strategy, from day one, needs to be clear communication via whatever channels are most appropriate, with all involved stakeholders. Like we said, you should start with clear expectations about how your infrastructure will be used going forward. Starting from the Assessment stage discussed above, sit down with leadership and tell them what you’re planning and ask for their input. These are the people who will be relying on the tools you’re deploying, so their needs must be taken into account from this early stage in order to avoid those pitfalls and missed requirements. Then, share your cloud strategy documents, the ones that thoroughly outline the project requirements and goals as discussed, in a central repository that all stakeholders have access to (like say a cloud-based document store?).
That is to say, know who knows what. Do you have a DevOps team that can automate your developers’ build pipelines as you introduce new platforms and tools into it? Or are you going to have to bring in outside help to usher that phase along? Do you have someone positioned to troubleshoot issues with the deployment down the road, or do you need to look outside for that?
Know not only what resources are available, but also to what extent they’re available. Is IT already working on 5 other projects, decommissioning 3 server farms, and deploying new laptops to the sales team? They might not want to hear about your awesome cloud idea right now. Was everyone recently sent a seminar to get certified on the scripting language that will allow them to do the big data move? This might be your signal to run the idea by the relevant team lead for feedback—you know, to make sure they’re ready. Otherwise, maybe propose a trial run using some archived data. This will ensure a smooth transition when you do move the live database, free from downtime or other unnecessary drama.
Don’t approach this step with a feeling of doom and gloom. If you find that your existing teams don’t have the know-how or the capacity for one or multiple elements of the modernization lifecycle, that doesn’t mean your cost management efforts have to be thrown off by new hires and overtime pay. By partnering with a services provider, for instance, you can gain flexible use of expert resources on your terms. This can be a huge boon from a cost management perspective, while also helping you access the experience that’s required to answer open questions about the right way to deploy and configure unfamiliar platforms, applications, etc.
As part of your resource assessment, keep in mind that upskilling is a great option. This is where you take an existing team and get them the skills they need to tackle a new project. For example, that IT team that just learned Javascript is now able to set up a data migration in a much cleaner way than before when they’d have been doing the move manually. Any chance to remove human error as a factor is a worthwhile investment of time and energy when it comes to ensuring the success of a cloud project.
At the same time, you need to consider areas where this might not be worth the investment. If it’s cheaper in the long run to work with an outsourced DevOps team, such that you’re able to focus your capacity and resources on creating the apps that will actually drive business growth for you, you may not want to expend existing resources on additional training right now.
In all likelihood, your job extends beyond the walls of the corporate office (or, these days, the remote corporate Slack channel) to include vendor management. This will certainly include cloud and platform providers themselves on the one hand, and might conceivably include any contract or outsourced work that’s being used to augment your internal team’s capabilities. With something as complex as a cloud migration, this aspect of the job is sometimes overlooked as a lever for managing budget through the modernization process.
First things first, you need to take vendor selection seriously at an early stage in the process. Look for someone who has certifications to show off. If you’re migrating to Azure, for instance, you might be particularly interested in Microsoft certified partners. You’ll also want someone who can talk frankly about cost expectations and the potential for cost savings. Once you’ve identified which areas require extra expertise or expert capacity, you’ll have to align with your potential vendor on whether they can provide experienced resources in those areas. As we’ve seen above, this is a process that is prone to disruption if you haven’t been a part of successful migration and management processes in the past.
At the end of the day, a services provider should be able to act as a trusted partner through the cloud deployment and beyond. You want someone with demonstrable experience who can help you pinpoint the areas you need help and then flexibly provide that help with an eye towards optimizing your unique situation. Like we saw above, modernizing your technology stack usually isn’t a “one-and-done” activity, which means that it’s worthwhile to partner with someone who can support you through the entire lifecycle.
Intertec’s teams have hands-on experience in developing and migrating applications on leading cloud platforms. In addition to design and development, we provide a complete range of application testing, deployment and on-going support services for applications and servers migrated to the cloud. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!