Slow Down Before You Speed Up


Take time to understand your IT estate before you build a cloud adoption plan


Justin Campbell CTO@junkshon


CIOs are under more pressure than ever to accelerate their digital transformation projects and shift workloads from on-premise to the cloud. The benefits of moving IT costs from Capex to Opex, the promise of dramatically increased agility (scale-up, scale back) and the opportunity to tap into a rich seam of innovation from major cloud vendors and their partners, look more and more attractive as we emerge from the constraints of COVID.


It’s understandable that companies want to move fast, but equally critical that they appreciate that cloud migration is a complex, potentially high-risk venture. If mistakes are made, or corners cut, early in the process, the costs can eventually outweigh the benefits. We see many long, painful migration projects grind to a halt and others where workloads are moved back on-premise because of unforeseen problems during or after the cloud migration (see my blog https://bit.ly/3ehJaZL).


The most important part of the pre-migration process is to undertake a full evaluation and analysis of your existing IT estate, both infrastructure and applications. This exercise, if conducted correctly, can deliver significant value long after the migration has taken place. And yet, this is the step where corners are most often cut, such is the temptation to just start lifting and shifting.

There are a few reasons for this, not least the perceived cost and the potential for this Discovery phase to drag from weeks into months. Standalone Discovery tools often come with big software licensing price tags, and can take months to roll out. They are also often not quite as ‘self-drive’ as they are purported to be. At the other end of the scale, much of this work is still done manually, with a picture of the IT estate being painstakingly documented in Excel spreadsheets. Each time a new inter-dependency is discovered, it has to be reverse-analysed and the whole picture rebuilt. There’s a graveyard of Discovery projects out there using this method that have run aground after costing millions and taken years.


The reason it’s so important to get this process right is that it’s incredibly rare for an IT department to know exactly what its IT estate looks like. In a de-centralised organisation, there are multiple stakeholders who’ve all been empowered to build their own IT ecosystems, so Discovery needs to identify every single stakeholder, every single application and then map inter-dependencies across the organisation. When we do this for our customers it’s rare that we don’t unearth applications they didn’t know existed. And while they might look like good candidates for a quick ‘lift and shift’, we’ll then discover that they are linked for four or five other applications, throwing up important control and compliance considerations.


These details will be missed if the Discovery process lacks the necessary rigour, and if they raise their heads much later (which they eventually will), they can delay the migration and erode the benefits of migration altogether. For example, one application like the one I described above might require a four-month refactoring exercise, pushing out the exit date from your data centre.


Even in a relatively centralised organisation, it’s rare for IT to have a handle on everything, due to rogue elements like ‘shadow IT’. Only when we run a full Data Discovery and Assessment can they see what’s been built up around the core apps ecosystem.


Cloud migration is actually a fantastic opportunity for a wholesale IT clean-up. A comprehensive Discovery phase can show you not only the complex network of inter-dependencies between applications but, just as valuably, systems that you just aren’t using. We often recommend to customers that they build in a retirement project at the same time they plan their cloud migration. Sometimes, there are literally thousands of servers that can simply be switched off. Why move (and pay for) workloads to the cloud when you don’t need them?


At this stage, you could be forgiven for thinking I’m describing a perfect world, and you might think that you don’t have the luxury of time or money to go the lengths I’m suggesting here. But actually, the IT Estate Discovery and Analysis projects we do for our customers typically take less than a week. That’s because we have a proprietary MCDB that accepts feeds from pretty much any source file, de-dupes it, maps it and then our platform applies machine learning to crunch through the data. There is no human intervention required at all while the AI engine is at work, but at the same time, we start getting useful insights almost immediately.


Also, you can continue to add more data over time as and when it becomes available, gradually enriching the overall picture of the IT estate. Discovery doesn’t need to be viewed as a one-time exercise.


4 Steps to I.T Estate Capture

So, comprehensive Discovery of your IT Estate is absolutely critical if you’re to execute a smooth migration strategy. It doesn’t have to cost you hundreds of thousands in license fees and it doesn’t have to take months. Junkshon provides a ‘pay as you go’ software/services model, and we can have your entire infrastructure and apps estate mapped and analysed in days or weeks.


And at that point, all the benefits of the cloud are a significant step closer.


To help you get started we have created this simple infographic on how we can help you get started with understanding your I.T estate.

19 views

Recent Posts

See All