The cloud represents a path forward for radical business transformation. Whether you're upgrading your on-premise infrastructure to run in the cloud, or transferring your server between providers, or launching a Mobile Device Management solution to manage your newly-remote workforce, your expectations are high. You know that with a successful cloud deployment you can gain better control over your computing, hosting, and IT costs, and you can become a more agile and responsive business. The question is, how do you get from here to there?
Some estimates say that more than 30% of cloud migrations fail. Why? Simply put, it's because of a widespread lack of experience and know-how. Luckily, Intertec's Cloud Services team has know-how and experience to spare—gained through many combined decades of industry experience, specialized tool usage, and cloud troubleshooting—which is how we help our clients beat the failure rate and successfully transform their businesses.
Whether you're migrating physical assets into the cloud or moving from one cloud provider to another, we've got you covered. In the planning stage, our team learns about the customer’s business and applications, as well as any relevant security concerns. Using this information, our team facilitates a smooth migration that avoids the pitfalls and snafus that can plague less experienced migration operations.
You need to make sure that your cloud deployment works for you, which means understanding how to optimize your costs based on your expected capacity needs. If you don't have the in-house expertise to configure and manage Azure or AWS with confidence, our team can help you right-size the deployment to provide potential cost savings of up to 70% compared to a mismanaged cloud service. This just one example of our full suite of cloud management activities.
One of our specialities is assisting with the remote management of physical infrastructure. This means applying upgrades and security patches, managing day-to-day maintenance, checking logs, and providing you with general health-checks for your infrastructure. This helps you keep your digital transformation on track and ensures that your technology integrated with your larger business goals.
Because its principles are designed to apply in a broad range of ecosystems, DevOps is ideally suited to outsourcing for teams that don't have the in-house capacity. You maintain control over your own workflows, while Intertec handles the nitty-gritty of your cloud infrastructure from an operations perspective.
Even experienced Azure of AWS users sometimes encounter questions they can't answer. When that happens, Intertec is only a phone call away. Whether your goal is to take some items of your internal IT staff's plate or to support teams that are just getting used to the cloud, we've got you covered. In this way, we work to offer full-lifecycle support for our clients.
Intertec International is an IT services company founded in 2002 and is headquartered in Phoenix, Arizona. We have nearshore locations in Costa Rica, Colombia, and Mexico. With 20+ years of experience in the IT industry, we have a proven track record of working with companies of all sizes from across the globe to solve their complex technical problems through customized solutions.
There are plenty of reasons why this part of the digital transformation process continues to present a huge challenge for people—companies feel pressure to modernize, but they don’t always know what they’re getting into. While it’s admirable that companies are jumping into new business realities with both feet, it’s critical to consider:
Without giving items like these the advanced consideration they deserve, you’re taking a big risk with your IT infrastructure.
Luckily, Intertec is here to help. From re-hosting to cloud-native development, we have developed successful strategies and playbooks that adapt to our customer needs.
We create cloud-native applications designed to embrace the most advanced and efficient cloud consumption models by leveraging microservices, containers and best-in-class PaaS, such as Azure Service Fabric and Mesosphere DC/OS.
Some CIOs and other stakeholders tend to think of cloud services primarily in terms of cost savings, but in point of fact they’re catalysts for much larger operational changes. The trick is to keep those changes in view while you’re making the transition. In a perfect world, this might involve a few steps:
This could be auditing your existing servers and software licenses, preparing any operational data for transfer, assigning roles for who’ll take charge of what tasks, etc.
This is where you figure out which platforms actually meet your needs most effectively—whether that means relying solely on Azure for your entire migration, creating a hybrid model with AWS, etc., as well as choosing the specific applications. Here, you’ll need to get a handle on how your existing infrastructure will slot into these new environments.
Before you go live with the new systems, you’ll need to make sure that you haven’t broken anything. As such, you’ll need a comprehensive testing plan that includes business cases relevant to your migration.
Finally, it’s time to cut the cord and switch your business over to the new cloud-based system or systems. It might seem like the job is done at this point, but in reality, this is a crucial moment for gaining buy-in from daily software users, getting the entire relevant team or teams on the same page with regards to new best practices, and dealing with any aftercare or troubleshooting that arises.
In a recent eBook, Gartner highlighted a handful of pervasive myths about the cloud: from “the cloud isn’t secure,” to “pure cloud deployments are the only viable option,” to “you can start implementing cloud technology without a strategy.” Left unexamined, these myths—and myriad others like them—can all easily set new infrastructure investments up for failure. At the same time, they’re not all equally pernicious.From our perspective, the idea that you can dive into a cloud deployment without a defined strategy is the most worrisome of the bunch. Why? Because it’s simply not accurate. Successful cloud migrations and modernization efforts require more than just a strong will—they require technological expertise, they require buy-in from multiple touchpoints in and out of the IT department, and they require a clear roadmap with measurable metrics for success. Without those critical elements, you run the risk of a costly, ongoing boondoggle. Rather than reining in costs and powering a more modern, responsive technology stack, you’ll find yourself throwing good money after bad to solve problems that could have been avoided at the outset.
In other words, you need a documented cloud strategy. And what form should that strategy take? One option is to create a cloud strategy document.
A cloud strategy document is pretty much what it sounds like. It’s a place for you to give an overview of how the cloud factors into your enterprise’s ongoing strategic initiatives, how you plan to get there from your current IT deployments, and what decision making heuristics you’ll use along the way. This shouldn’t come from a CIO’s head sui generis, but should instead be informed by discussions with stakeholders across multiple departments, plus cloud experts who can give detail to the exact ins, outs, and pitfalls that accompany each phase of the cloud lifecycle.
The purpose of getting all of this information into one document is twofold: to gain buy-in for your cloud migration plans, and to use as a touchstone throughout the process. There’s no way to cover everything that will happen from the word “go,” but you can create something that will help your colleagues to coalesce around your vision of digital transformation, making it that much more likely that your projects will come off and you’ll be able to modernize your stack while keeping costs under control.
So, fittingly, the first section of the cloud strategy document will start with a high-level summary of the project, what the aims of the project are, and how you plan to implement and measure the effects of the relevant changes. This include a sketch of your current IT landscape, your vision for the future of your stack, and a brief rundown of how each strategic initiative relates to corporate goals, plus the way the cloud factors into those initiatives and goals.
This is your chance to get everyone on the same page, so be sure to define your terms (you might lay out the difference between public, private, and hybrid clouds, the different cloud service models, NIST definitions of various technical terms, and more) and hammer home what you consider to be the most important points and the guiding principles that you’ll rely on as you move ahead.
In the next section of the document, you give a more detailed plan that covers the cloud migration on a workload by workload basis. Step one is to develop an inventory that lists out each and every workload within your existing technology stack. For each workload, you’ll want to give a full rundown of the costs and billing, the relevant vendor, the owner, any security and compliance requirements, plus a general rating of how suitable it is for the cloud. Something with unpredictable swings in data consumption or extremely seasonal processing needs (e.g. supply chain planning software for an automaker) could be a good fit for the cloud, whereas a stable, predictable application might be fine as-is, provided it’s appropriately provisioned.
All of this should be done with an eye towards categorizing each workload in terms its long-term migration status. Depending on how each workload slots into the larger framework, you might take one of a few paths in terms of application migration strategies:
There might also be workloads that you see no reason to change, or applications that need to be replaced with a similar offering from a new vendor (either in the cloud or not), or applications that need to be rebuilt from scratch. Denote these workloads as well. Based on the information you collate here, you can begin to set priorities for what will be migrated in what order.
You need a strategy for how you’re going to get from your current IT status quo to the cloud-enabled future—whatever that means to you—but you also need to give thought to how you’re going to make decisions once your cloud applications are up and running. Especially when it comes to cost management, you’ll have to take a proactive approach throughout the entire lifecycle of a given deployment, including monitoring your usage on various instances, tracking the performance of your applications, etc. This brings us to cloud governance, which is perhaps the biggest and most daunting part of the cloud strategy document. This can and should include tentative answers to a whole host of different questions:
You’ll want to provide as much detail here as possible, again so that others can use the document as a reference in the future. This will potentially require deep dives into the minutiae of everything from billing structures to new regulatory restrictions. If you don’t have the in-house expertise to handle all of this—and most businesses don’t—this is section is a prime opportunity to bring in a cloud expert who can help inform your governance and architecture decisions. Already at this stage of the process you might be thinking about who, exactly, will be doing what with regards to the modernization project, and how you’re going to stretch your capacity to cover all of the work—if that’s the case, it doesn’t hurt to be proactive about involving future migration and management partners.
Speaking of capacity: one of the most important steps here is to figure out who’s going to be responsible for what, and where the gaps are in available capacity and existing expertise. Start by listing out all of the roles (e.g. CIO, infrastructure manager, etc.) and giving a brief sketch of what they’re going to be responsible for. Ideally, the steps you’re taking throughout your digital transformation will give IT more of an ability to actively create value for the company as a whole, and your document should reflect your current thinking on that score, i.e. what your vision is for the futures of your different teams.
On a practical level, you’ll want to be sure that a number of specific responsibilities are accounted for and assigned to particular teams or individuals, e.g.:
In all likelihood, your exact answers here will adapt and change over time. The goal as you’re putting an initial document together is just to make sure that nothing flies under the radar. The last thing you want is to make the switch to Azure and realize several months later that your bills have skyrocketed because no one has been managing unused instances.
In this final section, you get a little bit deeper into the questions of implementation and integration that will define your actual cloud journey on an ongoing basis. This is where you’ll lay out the different project milestones, metrics for success, and criteria for completion. Even if you’re only undertaking a small fraction of your larger digital transformation, you’ll want to be explicit about what the priorities are for migrating different applications and workloads and what dependencies exist between them.
This section can also include your technical or budgetary requirements, your funding sources, and your initial assessments of prospective cloud providers. Ideally, this can work as a jumping off point to create tactical plans for the actual migrations—which will involve translating this high-level work into the thousands of individual tasks that comprise even a small migration project. Here, you’ll start to get a sense of what the gap really is between your internal capacity and budget realities and the amount of work that needs to get done.
At numerous points throughout the cloud strategy document, cost and TCO considerations will inevitably crop up. But how do you actually estimate what your TCO is going to be for a particular cloud service or platform? For starters, the various cloud providers all offer their own calculators for how much you might expect to pay on an ongoing basis:
Each of these tools can give you both a useful baseline and the basis for price comparisons (which will naturally factor into your cloud provider decision making process), but the Azure TCO calculator is in some ways the most interesting conceptually. It lets you plug in specific numbers for everything from hardware, software, and electricity to IT admin labor costs and specific storage-related costs. If you spend a few minutes playing around with the functionality based on your baselines, it’ll spit out direct cost comparisons for TCO 5 years out between Azure and on-prem storage and computing.
Here, two things might occur to you: First, because there are so many parameters to consider, the only way to get a robust, accurate estimate is to go in with a high baseline level of knowledge about your existing infrastructure and the way that you expect to architect your cloud deployment. In other words, you may need to take any sort of direct TCO comparison derived that way with a grain of salt, unless you’ve got a lot of cloud management expertise on tap.
Second, if you run through the calculations, you might notice that they don’t seem to take into account the lessons we learned from Gartner above. For instance, there’s likely going to be a period where you have both cloud infrastructure and physical infrastructure operating in parallel. An experienced team that’s performed migrations and modernizations in multiple different IT environments will be able to minimize the length of time that takes, but there will still be a period where you’re paying for cloud services while still operating on-prem servers. This means that your cloud TCO includes some physical computing and physical asset maintenance costs during the migration period.
By the same token, Gartner suggests that you’re probably going to wind up overpaying when you finally make the cutover and you’re trying to right-size your deployment, set up your reserve instances, etc. This means that the TCO you calculate up front will either reflect an overly conservative number—or it will show a number that’s much lower than your real costs. And this is before we even get into the question of whether your migration timeline is reasonable—considering that half of migration face delays due to lack of skills, this is something that you need to consider.
We’ve seen some of the ways that TCO calculations aren’t as straightforward as they may seem—but what about the costs themselves? Gone are the days when the cloud is automatically the cheaper option, but public cloud deployments are still going to represent the most flexible and dynamic options. The question is how to leverage that flexibility into the ideal balance between cost management and application performance within the context of technology stack modernization. Here, Gartner points out a useful distinction between cost reduction and cost optimization:
In an on-premise deployment, these considerations don’t exist in the same way. You can more or less tally up the cost of hardware, software, electricity, IT labor and other costs—taking into account the need for periodic upgrades and updates—and go from there. You may need to adjust over time, but you’ll be working within a framework that’s pretty familiar to IT generalists. With the public cloud, there’s an inherent level of complexity that makes it difficult to even reach an initial estimate for those who don’t have a lot of existing cloud experience.
This is all before we even get into cost comparisons between on-prem and hybrid clouds (the preferred deployment method for more than 70% of CIOs) or private clouds. These tend to be more expensive than public cloud deployments, but they also provide advantages in terms of how much control you have over your data and processes. Here, a similar set of questions and concerns will apply. And, again, it will be difficult to get an accurate read of the likely cost implications over the next 3-5 years if you don’t already have a strong familiarity with the cost reduction and optimization levers we alluded to above.
Let’s take a step back for a second. We sketched out a lot of complexities and grey areas above, and it might be offering a somewhat daunting picture of cloud migration and management, at least from a budgetary perspective. In reality, all we’re trying to suggest is that real cloud experts need to be brought in as stakeholders from the very first step in order to ensure that you’re looking at each stage of the process with the relevant context and background information. Whether you’re just starting to consider the feasibility of modernizing your technology stack, or you’re deciding between different providers and need to understand what your deployment will actually look like down the line, there’s value to be had in bringing in an expert advisor. Sure, some businesses already have experts on staff—but for those that don’t, it’s an important starting point even for the sorts of hypothetical TCO calculations we’ve been talking about.
Once you’re already reaching outside your organization for support, there’s actually a lot that a managed cloud solution provider can do to help you keep your TCO down right from the get-go. This starts with larger architecture questions and can continue, based on your precise needs, with rapidly scalable migration support, cloud infrastructure management, and even outsourced DevOps. By relying on the experience and expertise of a team for whom cloud deployment is routine, you can modernize more quickly and configure your initial deployment more accurately—and, as we’ve seen, both of those benefits can have a big impact on your TCO.
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 ongoing support services, including managing physical infrastructure and offering outsourced DevOps teams. Go ahead and schedule a meeting with us here to learn more!