My IT provider recommends Azure. How do you assess such a proposal?

Your IT provider presents a proposal. The current environment is beginning to age and, according to the provider, this is a good time to migrate part of the IT environment to Microsoft Azure.

The story sounds logical. Azure is a proven platform, the provider has experience with it, and the presentation highlights benefits such as flexibility, scalability, security and less concern about the underlying infrastructure.

Yet after the presentation, one question remains:

That is a healthy question. Not because there has to be anything wrong with the advice or the provider. The proposal may be excellent. But a good technical solution is not automatically the right solution for your organisation.

To assess that, I would therefore not start with Azure.

Start with the problem that needs to be solved

Suppose the provider says the current server environment needs to be replaced within two years. The proposed solution is a migration to Azure.

At first glance, the choice seems straightforward: do we invest again in our own infrastructure or move to the cloud? But that skips a step.

Why do the servers need to be replaced and what do we want to achieve by doing so?

Perhaps only the hardware is reaching the end of its life. But it may also be that the internal IT team wants to spend less time on technical management, applications are hitting capacity limits, the organisation is growing rapidly or continuity needs to be improved.

These are different challenges that can lead to different good solutions.

Does the proposal fit what the organisation needs?

Once the reason is clear, the proposal itself can be assessed. This is not only about technical requirements. The solution must also fit the organisation that has to work with it.

An organisation with a large internal IT department, extensive technical expertise and dozens of business-critical applications has different options and needs from an organisation with a small IT team that has outsourced almost all technical management.

Cloud also requires control over usage and costs. Without a good understanding of where costs arise and how they can be managed, actual costs may turn out differently from what was expected.

I therefore also want to understand what the organisation expects in the coming years. Which applications are important? What changes are anticipated? What expertise is available internally? What role should the IT provider continue to play? And how much flexibility is actually needed?

A detailed technical description of Azure can explain very well how the solution works, but it does not answer whether that solution fits the organisation.

Which alternatives have been considered?

One of the questions I almost always find interesting in an important IT proposal is:

Which other options were considered, and why were they rejected?

That does not mean every decision requires five fully developed designs. But a good proposal should show that alternatives have been weighed.

Azure may indeed be the most logical choice. Perhaps part of the current environment is better left in place. Some applications may now be available as SaaS solutions and may not need to be migrated to Azure at all. Or a combination of solutions may fit better.

A Microsoft-oriented IT provider will have extensive Azure expertise and will probably have built efficient services around it. That is an advantage. At the same time, the solution is partly viewed through the lens of the expertise and services the provider itself can offer.

It should therefore be clear why this particular solution has been chosen for your organisation.

Look beyond the migration

With major IT changes, the migration itself easily receives most of the attention. What will it cost? How long will it take? Which systems need to be moved and how do we minimise disruption?

But the consequences of the decision last much longer than the migration project.

What will our situation look like once the migration is complete?

What expertise will be needed then? Which activities will the provider perform and which responsibilities remain with the organisation? How easily can services later be changed or replaced? And what happens if usage grows faster than expected?

That is where it becomes clear whether a solution is attractive not only during implementation, but afterwards as well.

What will it really cost?

Comparing cloud costs only with the purchase price of servers rarely gives a complete picture.

A good comparison looks at total costs over several years: infrastructure, licences, management, support, connectivity, security, backup, required internal expertise and services from external parties.

A solution that looks more expensive on paper may reduce management risk or avoid upfront investments. Conversely, a solution with low initial costs may become more expensive over time as usage grows or more additional services are needed.

The goal is therefore not simply to find the cheapest solution.

What matters is understanding what you are paying for, which benefits you receive in return, and which costs and risks you accept for the coming years.

Which dependencies arise?

Every important IT decision creates dependencies. The current environment probably has them too: on hardware, software providers, specific expertise or the IT provider managing the environment.

Moving to Azure removes some dependencies but introduces others.

That does not have to be a problem. Complete independence from providers is hardly realistic in practice and is often not desirable. Specialisation and standardisation can bring substantial benefits.

What should be clear is which dependencies are being accepted consciously. How much of the solution is Azure-specific? What expertise is required? Could another IT provider take over management relatively easily? And what would it mean if the organisation wanted to change direction in five years?

Does the choice fit the future IT direction?

One risk with a technical proposal is assessing it in isolation. The solution may work well for today’s problem while fitting less well with where the organisation wants to go.

Suppose, for example, that the organisation plans to replace many existing applications with SaaS services in the coming years. The need for its own infrastructure may then change significantly. In a planned acquisition, flexibility may become particularly important. And if data and AI are to play a larger role, other aspects of the platform may become relevant.

The assessment should therefore also ask:

Does this choice only solve today’s problem, or does it also support the direction in which the organisation wants to develop?

Not everything for the next five years needs to be fixed. But an important IT decision should preferably enable future choices rather than unnecessarily restrict them.

And perhaps Azure simply is the right choice

After all these questions, the conclusion may well be that the IT provider’s proposal is excellent.

Azure may be a strong technical fit. The costs may be justified. The organisation may benefit from its existing provider’s expertise, and the solution may align with future plans.

An independent assessment is therefore not a search for flaws in a proposal. Nor is the aim to put the IT provider and customer in opposition.

The aim is for an organisation to make an important decision because it understands why the proposed solution fits, what alternatives exist, what consequences the choice has and which risks it accepts.

For a decision that may influence your IT landscape for many years, that is an important difference.