Companies are investing billions of dollars migrating workloads to the public cloud, yet the vast majority of workloads are still on-premises, with many IT leaders finding their cloud projects stalling after migrating a few workloads. Despite their goals to be “cloud first”, many companies are running only a fraction of their application portfolios on the cloud, facing challenges across budget, staffing, and executive buy-in.

In this short guide, we’ll explore the top reasons cloud migration plans stall and recommend next steps for restarting your cloud migration efforts. We’ll rely on real examples of cloud migration projects and the latest research to help get your migration projects back on track. 

The State of Cloud Adoption: A 10,000 ft. View

“Through 2022, insufficient cloud skills will delay half of enterprise IT organizations’ migration to the cloud by two years or more.”
– Gartner: 4 Trends Impacting Cloud Adoption in 2020

It is very common for cloud migrations to stall. If you’re like most companies, you began with the goal of migrating the majority of your workloads to the public cloud and perhaps have already migrated your first POC application or group of applications. But at some point during that process, your cloud projects stopped. The following data proves you’re not alone: 

• • 90% of CIOs have already experienced data migration projects not going as planned due to the complexity of moving from on-premises to the cloud. Only a quarter met their deadlines for such data migrations, with the average data migration taking 12 months. (Source: Cloud Security Alliance 2019)
  • 94% of IT leaders believe their company has significant barriers to implementing their cloud strategy. (Source: Logicworks 2020)
  • 62% of companies said their cloud migration project was harder than expected, and 55% went over budget. (Source: Velostrata/Dimensional Research 2017)

This explains why the average company has only progressed 20% in their cloud transformation efforts. Datacenters are still the core foundation of enterprise IT — and will be for the next 10 years. 

That said, organizations still plan to invest heavily in cloud — even though their current projects are over-budget. According to the 2020 State of the Cloud Report, organizations are projecting an average 47% increase in cloud spend in the next 12 months, while 56% plan to spend more than they expected due to the ongoing impacts of COVID-19. 

Volumes have been written about the current state of cloud adoption. But suffice it to say that there is an intense desire for more cloud projects but also some significant adoption pain-points that are causing projects to proceed slower than expected.

How Cloud Migrations Stall

Every cloud migration project is unique, but most failed or half-complete migration projects share at least one of the following challenges. 

In this section, we’ll present recent data pulled from a research report conducted by Wakefield Research of 400 IT decision makers.

#1: Lack of Executive Understanding and Top-Down Strategy

“The first element of any big type of transformation is not technical. It’s all about leadership. If you don’t have senior management alignment, you won’t make that change.” – Andy Jassy, CEO of AWS (during AWS re:Invent 2019 keynote)

Cloud teams want leadership to recognize what they do, understand the cloud, develop strong cloud goals, and invest in successful outcomes. One of the biggest reasons cloud migrations stall or fail is lack of executive strategy and understanding of cloud technology.

More than 4 in 5 (84%) of IT professionals say executive leadership doesn’t understand enough about what they do, and 34% say a lack of defined strategy is a top barrier to cloud success. 

While this may appear straightforward, the dynamics of communication, trust, and levels of technical expertise can cause the relationship between staff and leadership to fail. Lack of executive leadership results in many interrelated issues that can poison cloud projects.

 “Doing Big Things” in the Cloud: A Real-Life Anecdote

Logicworks recently worked with a company experiencing stalled migration projects. They were unable to determine the disconnect, so our team met with the company’s CTO to learn more.

They discovered mid-level IT managers were telling the CTO that they were “doing big things in the cloud”.  We looked at their accounts, and came to find out that they were only running three AWS EC2 instances. Armed with this information, the CTO went back to his mid-level managers and asked why they claimed to be “doing big things” if there were only three instances running. The CTO became more involved in the details of migration, and together they came up with a plan for success. They went from running three instances to several hundred in under a year.

The anecdote above shows what happens when the C-Suite doesn’t fully understand the cloud, resulting in a lack of top-down goals for the cloud. A goal should be easy to understand with a defined timeline, such as,  “Migrate 30% of back-office workloads to AWS by 2022.” If there’s no comprehensive top-down goal, chances are the IT team will take the path of least resistance.

The Frozen Middle 

The narrative above also highlights what happens when executives aren’t fully aware of what mid-level managers are asking their teams to prioritize day-to-day. Engineers and executives are ready for the cloud — but mid-level managers focus their teams on other projects. Why? Because cloud migration is perceived as high-risk, and there are always a million other things to do. 

This is often called the “frozen middle”. The solution: greater visibility from executives into engineer priorities and better KPIs to track how middle managers are achieving these goals. However, it’s the executive’s responsibility to support mid-level managers by giving them the time and space to achieve these goals. Executives need to make the tough decisions about what competing projects need to be delayed in order to prioritize cloud migration. 

Companies Need A Better Strategy, Not More Tools

Humans tend to overemphasize technical solutions to behavioral or strategic problems. While IT leaders recognize that most roadblocks to cloud adoption are non-technical, the majority of IT leaders (61%) still prioritize technical solutions like investing in better cloud tools over getting more executive buy-in (39%).

This reveals a common problem in IT teams: when something’s not working, we look for a tool to fix it. It’s so easy to get so wrapped up trying to identify and implement the newest and hottest tools that we fail to tackle bigger issues, such as lacking alignment around cloud or effective management processes. We prioritize tools over strategy.

Cloud teams want leadership to understand what they do, understand the cloud, develop strongcloud goals, and invest in successful outcomes. In order to achieve cloud goals, senior leadership must get more involved in cloud strategy and develop stronger top-down goals for cloud growth. Or perhaps you have strong cloud goals, but aren’t communicating them properly, or aren’t communicating often enough when goals change. Enterprise IT organizations need to understand that given the fluid nature and speed of cloud, they will have to adopt a 360 degree management process where they present timely information to teams and team management, and they get KPIs back in a timely fashion to ensure that they’re demonstrating progress. 

This year, make it a priority to discuss what’s working, what’s not, and make reasonable goals for the cloud. Meanwhile, don’t get lost in the swamps of tool selection and forget what really matters: shipping products. Pick one set of cloud-native tools and stick to it.

Next Steps

Does this sound like your team? Here’s what to do next, per experts like Mark Schwartz, the head of AWS Enterprise Strategy and former CIO of Dow Jones: 

1. 1. Go backwards and re-build or refine your business case. Many companies in their initial migration to the cloud don’t bother to develop a business case. When we say develop a business case, we mean a detailed explanation of why migrating to the cloud is beneficial, a risk assessment, a list of things that could go wrong, ways to mitigate those risks, financial models (usually the result of a TCO Analysis), and a business value analysis. You should then revisit this business case at every stage of migration. For advice on how to build a business case for cloud, we like this documentation (which can be cloud neutral).  It’s also key that your business case is meaningful beyond the technology team, to everyone from upper management to end users. For instance, your sales team may have to agree on the business case for a sales database move, especially if you’re trying to re-kick off a process that failed last time. 
   2. Set an unambiguous goal. A slide in your quarterly meeting that says “Cloud First” on it is ambiguous. A company-wide goal of “Move X and Y applications to AWS in six months” is not ambiguous. We’re always amazed by how often well-meaning but ambiguous goals trip up cloud teams. These goals need to have clear KPIs that are regularly tracked at much greater frequency than the quarterly meeting. 
   3. Reduce the scope of your goals. The other problem with broad, overarching goals is that your team doesn’t know where to begin. Choose a small set of applications and a timeline that is compressed but not unreasonable. 
   4. Remove or delay competing goals. There’s only so many big goals an IT team can meet in a short period. For example, we’ve watched many companies try to simultaneously do a complete overhaul of their main application and migrate to the cloud in the same short period. Their success rate is abysmal. Your team can only do one big project at once. 
   5. Build a Cloud Center of Excellence (CCoE) or DevOps team or Cloud team — whatever you want to call it. A CCoE is a small group of engineers and leaders dedicated to bringing the first set of workloads in the cloud — or perhaps in your case, fixing what’s on the cloud today and migrating the next workload. This can be a helpful concept if you’re struggling with focusing your team on migration, but don’t let it become a bottleneck. A CCoE is not a cloud governance team, and is not responsible for approving or reviewing all cloud work, this role is filled by your Cloud Leadership Team. It’s the opposite: building reusable, repeatable architectures and laying the groundwork for future migrations. If you’re interested in building your own CCoE or Cloud Leadership Team, read “Reaching Cloud Velocity” by Jonathan Allen and Thomas Blood. 
   6. Highlight existing successes. Chances are that this isn’t your first time trying to migrate to the cloud. Even if your first few workloads weren’t perfect — what went right? What datacenter space were you able to close? What internal competencies did your team gain, even in the midst of issues? Take a step back and ask your team to contemplate positive efforts, even if they weren’t perfect. 
   7. Listen. Leadership is not just about telling everyone what to do. If members of your IT team feel unheard in this process, they’ll resist you at every step. So take time to sit down and listen to each team member — if possible, without middle managers present. You’ll learn a lot about what really happened the first time you tried to migrate to the cloud. Make changes to your planning that reflect their feedback. Remember, your team has experienced failure and is likely in the “valley of despair”. You need to guide your team through the Dunning-Kruger effect, through the slope of enlightenment and up to the plateau of sustainability. That said, only listen to excuses about why team members don’t want to/can’t move to the cloud once. Then ask everyone to move forward. 
   8. It’s not about you. It’s about the business case. Engineers are stubborn. But they’re also naturally data-driven. If you show them data on why moving to the cloud makes sense, they’ll listen. 

#2: Lack of Appropriate Staffing

Finding qualified cloud engineers is hard. 86% of IT decision makers believe that a shortage of qualified engineers slows down cloud projects, while 63% of senior executives say a talent shortage is one of their organization’s “major concerns”.

Cloud engineers are the 3rd hardest IT job to fill in America, behind cybersecurity and data/AI. Any engineers that you hire are also hard to keep, with half of them getting contacted by recruiters at least once a month.

While this issue seems relatively straightforward, it’s actually several issues rolled into one. Let’s dive in. 

Hunting for Cloud DevOps Unicorns

Companies with less experience in cloud systems often go searching for cloud engineers with a very long list of requirements. The engineer must have a Computer Science degree, traditional systems experience, 5+ years of cloud experience, experience in containers and automating CI/CD pipelines, and hopefully some security and compliance skills thrown in. We’ll call these “Cloud DevOps Unicorns”.

As the name implies, these engineers are a rare breed. Remember: the public cloud has only been around for a little over a decade, and a very small percentage of teams have been through a successful legacy-to-cloud transformation. That’s a small pool of talent. The vast majority of cloud engineers are relatively new to cloud, with one or two years of IT support experience and hold an Associate-level cloud certification, and some don’t have traditional systems or Computer Science experience. We like to say that 1 year of cloud engineer experience = 3 to5 years of experience in another area. You might be surprised about what a born-in-the-cloud engineer with just a year of cloud support experience can bring to your team. 

Our advice: don’t let your search for the “ideal” cloud engineer prevent you from moving forward. Try one of these three things instead:

1. 1. Your internal team should be led by a Cloud DevOps Unicorn while the rest of your team  should consist of more junior cloud engineers or existing systems engineers who can be trained. 
   2. Hire one Cloud DevOps Unicorn as the architect and visionary. Work with him/her to outsource the actual work of building and maintaining the cloud to a cloud partner.
   3. Elevate a small number of internal team members to participate in extensive cloud training, then use them as team leads in migration. Use a cloud partner to mitigate the risk of having new cloud users in production systems. 
   4. Look at leveraging Site Reliability Engineers if your needs focus on the infrastructure. 

In our experience, the easiest group of engineers to train into Cloud DevOps Unicorns is traditional systems engineers. At the end of the day, cloud engineering is still servers and networks, and systems engineers inherently understand concepts like reliability.

When “We Don’t Have Enough Engineers” Actually Means “We’re Asking Too Much of Our Engineers”

As engineers and IT leaders,  we like the idea that there’s a clean end to one system and a fresh start to a brand new one — with a new containerized application, CI/CD pipeline, infrastructure-as-code perfectly tuned, etc. This impulse towards perfection, plus all the stories and case studies about Netflix, GE, etc., paint this picture of “cloud utopia” where all your problems are automatically solved and there’s no more 3am failures or unexplained errors. If only you could have a few more Cloud DevOps Unicorns to refactor your applications and move you to the cloud quickly, cloud utopia could finally be achieved, right? 

In this scenario, your problem isn’t actually a lack of staff, it’s a lack of managed expectations. The idea that your applications have to be perfect before migrating to the cloud is not realistic. Remember: Cloud utopia doesn’t actually exist. Even the most sophisticated cloud platforms on the planet have flaws. 

We can’t even count the number of times that a company has approached us with great enthusiasm for migration, met with us to assess and design their target cloud infrastructure, and then disappear for 12-18 months while they redesign their application — all while the cloud infrastructure is just sitting there. Cloud partners can help to fill a big skills gap in your organization, but in cases like these, it’s about unrealistic expectations of perfection.

Next Steps:

1. 1. Rely on your business case to advocate for more engineering talent. Use all of the goal-setting and information-gathering you built in the previous section and use it to advocate for bigger budgets. 
   2. Lose your obsession with “cloud utopia” and focus on the task at hand. Your legacy apps will never be transformed into the perfect, cloud-native application. Set a deadline, finish whatever high-impact, medium-to-low effort changes you can during that time, and lift-and-shift. (Tip: Biggest impact change is likely moving your database to a fully managed database.)
   3. To partner or not to partner? While we may be biased, we think that the most successful cloud projects use one or several partners to get the job done faster and with fewer mistakes. Whether it’s just some engineers-by-the-hour or outsourcing the whole project to a partner, it’s the fastest way to fill a staffing gap. 

#3: Compliance Issues

A whopping 88% of IT leaders at mid to large sized companies agree that having to meet compliance standards in the cloud inhibits further cloud adoption within their company.

Why is compliance such a big roadblock? Is it because of lack of experience among IT teams, or is it the cloud platforms themselves?

Major cloud platforms like Amazon Web Services (AWS) and Microsoft Azure service thousands of customers in highly-regulated industries. They have prioritized services that automate security and compliance tasks. In short, public cloud providers have made significant investments in tools, documentation, and audits to enable compliance on their platforms. It is unlikely that cloud platforms themselves are inhibiting adoption. 

The real culprit? Compliance on the cloud can be confusing, hard, and expensive.

Confusion about Compliance on the Cloud

49% of IT leaders believe that cloud providers are responsible for compliance in the cloud.

Unfortunately…they’re wrong.

Cloud providers like AWS are very clear on this point: “While AWS manages security of the cloud, customers remain responsible for compliance and security in the cloud.” The company, not the cloud provider, bears contractual responsibility for compliance. 

For example, AWS provides the Identity and Access Management (IAM) tool and is responsible for the IT controls in place that govern access to the physical infrastructure that holds your access policies, and customers are responsible for the setting up and maintaining roles and users in IAM. Inappropriate or unauthorized usage of an AWS resource as a result of inadequate IAM controls is the customer responsibility.  

Long story short, there’s a lot of complexity around compliance responsibility which slows down cloud projects. 

Executives must understand compliance responsibility in order to successfully operate on the cloud. Further training is required to educate leadership and engineers on how to host regulated data on the public cloud, which will also reduce resistance to migrating compliant workloads to the cloud in the future.

Compliance is Time-Consuming and Expensive

A recent Globalscape and Ponemon study found that, on average, 14% of IT budgets were spent on compliance. A mid-sized company in a highly regulated industry — like a healthcare SaaS company — can spend an even more significant portion of its overall budget on compliance. 

All the 3rd party tools, IDS licenses, and machine images you pay for or custom build on-premises, you now have to duplicate on the cloud. That’s a major drain on engineering hours and IT budgets. It’s no surprise then that 82% of IT professionals wish more cloud compliance tasks were automated.

Next Steps:

• • Centralize Cloud Governance. Centralizing cloud governance processes can save you a lot of time and money. In fact, a recent study found that the average mid-large sized company can save up to  $3 million on compliance by centralizing governance tasks. At Logicworks, we’re annually audited for HIPAA, PCI, SOC 1, SOC 2, HITRUST, and ISO 27001. For a mid-sized company, that’s a big lift. To help us keep up, we maintain a multi-regulatory compliance model where we have a single set of standards to meet multiple compliance frameworks. One central standard, multiple frameworks. 

It certainly is easier said than done. In fact, it took us several years and audits to develop it. To get started on this process, we recommend the following resources:

• • Cloud Security Alliance (CSA)’s Cloud Control Matrix 
  • Continuous Compliance on AWS 
  • Security Risks in Public Cloud: Introduction to Threat Modeling 
  • Threat Modeling 101 for Public Cloud – Threatstack
  • CSA AWS Questionnaire – Answers most common compliance questions 

Train Your Staff

Obviously, a key way to unstick the migration of compliant workloads is to either improve employees’ compliance education or hire compliance-savvy engineers. 

However, only 47% of engineers report that they don’t receive any security or compliance training annually. This is a serious gap in training and education. How can we expect engineers to migrate workloads whose requirements they don’t fully understand?  

The first step is to make self-learning modules available. Then pay for in-person staff training. 

• • AWS Auditor Learning Path (Free)
  • CSA Enterprise In-Person Training (Fee Required)
  • SANS In-Person Cloud Security Training (Fee Required)

Consider Outsourcing

40% of IT leaders plan to hire more outside consultants to help them manage their cloud. Compliance expertise is a key factor in many companies’ decision-making processes. 

This additional cost may be mitigated by two factors: the lower total cost of ownership associated with most cloud platforms and leveraging 3rd party providers, like Logicworks, to bear the cost and maintenance responsibility for infrastructure-related compliance tasks.

#4. Cloud Management Issues

Major cloud platforms like AWS and Azure provide built-in tools to simplify ongoing management. However, this can lead IT leaders to mistakenly believe that maintaining their cloud systems will be easier than on-premises. In reality, moving to the cloud means you have outsourced racking and stacking servers. Your IT team still needs to do things like: configure networks, maintain permissions, lock down critical data, set up backups, create and maintain machine images, and dozens of other tasks that cloud platforms do not perform. 

The assumption that cloud management is “easy” has also been reinforced by thought leaders in the cloud industry, who put forward case studies of enterprises that manage thousands of instances with only a small team of employees. So how do they achieve this? 

The cost and time required for cloud management can vary widely depending on how frequently you add/remove cloud resources, how many VMs/instances you manage, and whether or not you take advantage of fully-managed cloud-native services (i.e. Amazon RDS). But by far the biggest impact on these estimates is whether or not you automate certain cloud management tasks, such as instance build-out, patching, or alerting. The enterprises that manage huge cloud environments with “minimal” effort actually spend a significant amount of time and budget automating every aspect of their cloud environment, including an entire staff of people dedicated to maintaining this automation. Additionally, it is probable they rebuilt their software to work with serverless services. This can cause unrealistic expectations of your own internal team, and is one of the main reasons leadership underestimate cloud management and under-hire. 

Here’s just one estimate of the amount of time it takes to manage cloud resources, based on the size of your environment:

Cloud Management Time and Staff Estimates

Problems with Lack of Cloud Management Planning

Insufficient planning for cloud management can have serious consequences for the long-term success of cloud projects, possibly resulting in:

1. 1. Stalled cloud migrations due to overwhelmed operations staff
   2. Isolated cloud projects without common, shared standards 
   3. Ad hoc security configurations, due to a lack of common benchmark or inconsistent application of that benchmark
   4. Shortage of shared resources and learnings across teams, leading to further inefficiencies
   5. Inadequate, inconsistent financial data for tracking purposes

When you combine insufficient cloud planning and increasing pressure to deliver infrastructure faster and more reliably, you can see why IT teams are struggling to keep up. These pressures sometimes cause cloud projects to falter and stagnate after the first wave of migration; they have one or two moderately successful projects, but do not know how to expand usage with the proper controls across the enterprise. The company usually gets some cost benefits from migrating, but does not get the agility benefits they expect. 

Should You Hire an MSP?

Companies that want to reduce the IT management burden on their in-house team hire a Managed Services Provider (MSP). 

MSPs do most of the tasks described in this section. In some cases, they replace an in-house cloud support team and in other cases, MSPs act as an extension of the in-house team, doing the “heavy lifting” so that the in-house cloud team can do more differentiating tasks, like innovation and experimentation. 

Early in the process of interviewing MSPs, you should ask for a copy of their Responsibility Matrix to clearly identify who is responsible for  what. (If they don’t even have a Responsibility Matrix run away.)

Next Steps:

• • Read the Guide to Cloud Management. Every task you need to plan for, how much it costs the average company, and the engineering talent you need to do them — all in 20 pages. It’s required reading for any IT leader. 
  • Audit your current cloud resources for Operational Excellence. Rely on the Well-Architected Framework to give you a detailed list of best practices you should be applying in cloud management. Both AWS and Azure follow a similar framework. Chances are, once you implement some of these best practices, the less stress your internal IT team will face, and the more time you’ll have for your next cloud migration project. 
  • Establish a single set of cloud management standards. Write them down. Don’t assume they’re understood by everyone on your team; work to codify them in infrastructure templates so that those standards are repeatable and easily deployed. 
  • Consider outsourcing non-differentiated tasks. If your team can’t migrate more workloads to the cloud because they’re busy patching, backing up, or deploying new infrastructure, you’ve got your most valuable engineers working on non-differentiated tasks. Instead, focus them on things that matter, like migrating additional workloads to the cloud.

#5: Cost Issues

Cost control is a crucial aspect of any cloud management practice. Many organizations list unpredictable costs as a top issue, and nearly one-third struggle with a lack of visibility into cloud resource usage. 

These frustrations have big down-stream impacts and can cause companies to stop migrating workloads to the cloud, stall major projects, and cause long-term tension between technical and business teams. 

Cost Management Platforms Are Great…But Not Enough

Many IT teams try to control costs by using a cost management platform. There are hundreds of great cloud cost management platforms on the market and all of them provide better alerting and historical tracking for cloud costs. 

Cost management platforms can tell you that costs are spiking or unusual, but they can’t provide engineers with alerts to investigate and fix issues, and can’t report to the finance team for you. In addition, they can’t purchase and manage Reserved Instances/VMs — which in some instances is a full-time job. 

Cloud cost management requires engineer hours every month and regular review from IT leadership.

Who Owns Cost Management?

The #1 struggle with cloud cost management we’ve seen is lack of ownership in cloud teams. Billing is not usually the responsibility of engineers, and cloud bills are too technical for finance teams, so it often ends up landing on the IT manager or CIO/CTO’s desk, who don’t have time to examine costs closely. This is why it’s so easy for costs to get out of control.

Unreasonable Expectations of Cloud Cost Savings

If your team or leadership has high expectations of the cloud automatically saving money, leadership will likely get turned off at climbing cloud costs. 

Many organizations fail to properly budget for cloud migration, often missing the need to treat costs as an ongoing, rather than finite, expense. The recent report found that less than 40% of firms were able to predict cloud platform costs, and 58% said costs were higher than estimated. Organizations also underestimated people and tool costs.

“A major component of dissatisfaction with public cloud migration is cost complexity. Cloud platforms promise greater agility and flexibility using dynamic cost structures to align spend with usage. While this pay-per-use model has the potential to curb spend on transient workloads, unpredictable user patterns translate to unpredictable costs.”

– Forrester + CloudHealth Report, 2017

Unpredictable costs are the nature of the cloud. Below are some tips to anticipate the unexpected.

Next Steps:

• • Do a deep dive on cost analytics for previous/current cloud efforts. What exactly went wrong or is going wrong now with your initial cloud efforts? “My cloud bill is too high” is not a helpful starting point. What service is costing too much? What’s the budget you’re trying to meet? Which particular application function is being affected? 
  • Understand the true source of costs in early cloud migrations. Chances are, in early phases of migration, you’re paying to host the same application on both your source infrastructure and your target cloud infrastructure, sometimes called the “migration bubble”. For some companies, this bubble only occurs for a couple months. But for companies whose cloud migrations have stalled, the bubble can last for years. That’s why speed of migration and upfront planning are so important. The analysis you performed in step 1 should help guide you towards the real source of costs in your migration efforts.
  • Purchase Reserved Instances. It’s the single most effective way to reduce cloud costs, often by 20-50%. Word of caution: track at least a year of data before purchasing RIs. Our resident RI expert distilled all of his RI wisdom here. 
  • Put guardrails in place to alert you of unexpected cost increases. Set up custom alarms or your cloud cost management portal of choice. That way, you get alerted whenever you cross a specific threshold, rather than getting a surprise bill at the end of the month. 
  • Tag everything. By default, your cloud bill will tell you how much your business spent overall on specific services (“AWS EC2 Service = $X, AWS S3 = $Y”), but businesses gain more from the cloud by understanding costs on a more granular level. Calculating the specific infrastructure costs on a product or component level allows businesses to logically invest, and avoids a “black hole” of infrastructure costs. If you are just beginning this process, we suggest sticking to just a few dimensions, like Environment, Tier, and Team. You could then potentially break down a resource cost by Production / Dev, Database / Web, or by Critical Project 1 team / Application 5 team, for instance. Then automate tagging in your infrastructure templating tool. 

Summary

Getting stuck in the middle of a cloud migration project is common. But if you apply the right pressure in the right places, it’s possible to reboot your projects and get back on track. 

If you’re looking for outside help getting un-stuck, please feel free to reach out to the team at Logicworks. We offer consulting and workshops specifically designed for stalled cloud migrations and can usually help companies get back on track in less than a month. Contact us to learn more. 

About Logicworks

Logicworks is a leading provider of cloud migration and managed services. As an AWS Premier Consulting Partner and Azure Expert MSP, we have helped hundreds of companies architect, migrate, and manage custom cloud environments. We specialize in complex, highly regulated workloads for healthcare, finance,
and retail and have earned HIPAA, HITRUST, PCI-DSS, SOC1, SOC2, and ISO 27001 certification. Learn more about Logicworks at www.logicworks.com.