Today, infrastructure modernisation is changing not only the technology, but also the cost structure, the way IT operates and the resilience of the entire company. Choosing a partner is therefore no longer simply a matter of purchasing services. It is a decision about who will influence the pace of the company’s development and its ability to continue operating during outages over the coming years.
The biggest mistake remains judging partners primarily by the number of certifications, manufacturers’ status and the size of their team. Such information confirms technical expertise, but does not show whether the supplier can tailor the technology to the business, keep costs down and leave the company capable of managing its environment independently.
A good partner does not build its advantage on the client’s long-term dependence. Its value is evident in whether the company understands the new environment, controls it and is able to develop it further without the constant presence of external consultants.
Results first, technology second
Companies often begin their modernisation journey by asking which cloud or platform to choose. Yet technology is a tool, not the aim of the project.
The starting point is answering the question of what the modernisation is intended to change. This may involve reducing service deployment times, improving availability, cutting costs, enhancing security or preparing the infrastructure for AI applications. Without a clearly defined outcome, every supplier interprets the client’s needs through the lens of their own offering.
A partner specialising in a single cloud will naturally be inclined to recommend that very cloud. A company that generates revenue from licences may prefer an architecture requiring a greater number of products, whilst a managed services provider may favour a solution that is difficult to maintain without their involvement.
This does not mean they are acting against the client’s interests. It does, however, show that a partner’s business model influences their recommendations. Therefore, the more precisely a company defines the expected outcome, the lower the risk that the project will end in technical success without clear business value.
A good partner starts with an assessment
The quality of a partner can be assessed even before the contract is signed. The way in which they analyse the client’s environment speaks volumes.
A mature provider does not start by presenting their own services. First, they map the interdependencies between applications, data, infrastructure and business processes. They are interested in which systems are critical, how much downtime costs, where bottlenecks lie, and which capabilities the company wishes to retain in-house.
It is also important to be prepared to question the very need for migration. Some applications are better left in their current environment, others require a redesign, whilst still others can be replaced by an off-the-shelf service.
This is why the ‘cloud-first’ approach is losing its relevance. The location of a system is increasingly determined by costs, security, regulations, latency and resilience, rather than the supplier’s sales strategy.
A partner who is too quick to recommend a single technology is likely to be tailoring the client to their own solution. One who is able to challenge the company’s initial assumptions may protect it from a costly modernisation carried out in the wrong direction.
It’s the team that counts, not the logo
A big brand provides scale and access to expertise, but does not guarantee that the experts presented during the sales process will actually be assigned to the project. That is why the composition of the specific team is more important than the integrator’s logo.
Before signing a contract, it is essential to know the names of the people responsible for architecture, migration, security and maintenance. Their availability, substitution policies and the involvement of subcontractors are also important.
References are only useful if they relate to projects similar in terms of scale, criticality and complexity. Migrating a support system does not prove that a partner can handle an environment on which sales or production depend.
The way problems are described is more revealing than a list of successes. A partner who can explain how they dealt with a failure, a delay or a mistaken assumption provides a better picture of their competence than a company that only showcases flawless projects.
Resilience must be seen in action
Migrating to a modern environment does not guarantee business continuity. It may even create new points of failure.
Systems operating across different clouds may still rely on the same identity provider, network operator, security platform or management tool. A failure in any one of these components can bring the entire environment to a standstill, despite the infrastructure being formally distributed.
Therefore, claims of high availability are of limited value without failure scenarios, recovery procedures and tests. What matters most to a business is not whether a single server is working, but whether the company can continue to fulfil orders, serve customers and maintain production.
The best test remains a real-world recovery test of the entire business process. Only then can it be seen whether the architecture, procedures and division of responsibilities also function under time pressure.
The cheapest offer may turn out to be the most expensive
The cost of modernisation does not end with the partner’s fee. It also includes the parallel maintenance of the old and new environments, data transfer, licences, security, monitoring, training and ongoing support.
The new architecture may require more expensive specialists, a greater number of tools and the ongoing involvement of consultants. An offer that seems attractive at first can therefore result in high operating costs in subsequent years.
A better benchmark than the implementation price is the total cost of running the environment over a period of several years. The unit cost – for example, per transaction, per customer or per product – is even more revealing. A rise in costs is not a problem if the scale of the business is growing at the same time. The problem arises when costs rise faster than the value delivered.
The partner’s remuneration model is also significant. If their revenue increases in line with infrastructure usage, their incentive to simplify the environment may be limited. If they are billed for consultants’ time, automation may work against their economic interests. It is worth taking these factors into account in the contract and project metrics.
The exit strategy begins before the contract is signed
Companies usually only consider changing providers once the partnership has broken down. In the case of infrastructure, such reflection often comes too late.
Right from the start of the collaboration, the rules governing ownership of the automation code, configuration, documentation and operational data are crucial. The greater the client’s access to these resources, the greater the freedom to further develop the environment and, if necessary, change providers.
Equally important are the data export format, the cost of migration support and the time required to wind down services. Without such arrangements, the partner may gain a technical and organisational advantage that makes it difficult for the client to leave, even if the quality of the partnership declines.
An exit strategy is not an expression of mistrust. It is a tool for maintaining balance in the relationship and a strong negotiating position throughout the duration of the contract.
Knowledge transfer is part of the outcome
A company that is unable to carry out basic operations independently after the project has concluded has simply swapped its old technological debt for a new dependency.
Knowledge transfer is of greater value when it takes place during the project, rather than during a few training sessions at the end. Joint design, migration, problem-solving and the documentation of decisions enable the client’s team to gradually take over responsibility.
A good measure of success is therefore not solely availability or performance. Equally important are the level of automation, the quality of documentation and the number of processes that the in-house team can manage without external assistance.
The greater the organisation’s autonomy following implementation, the greater the value of the entire modernisation project.
The safest approach is to start with a pilot
Selecting a partner based on a presentation and a response to a request for proposal always involves an element of risk. This risk can be mitigated by a paid diagnostic assessment and a well-designed pilot project.
The first stage allows you to assess the partner’s approach and the quality of their analysis. The documentation from the assessment provides value to the company regardless of whether the collaboration continues.
The pilot project, on the other hand, demonstrates how the partner operates in practice: how they respond to problems, control costs, document the environment and collaborate with the client’s team. Only real-world work reveals whether they are capable of managing complexity, or whether they are merely good at presenting their capabilities.
A positive outcome from the pilot provides the basis for extending the contract. A negative outcome allows the collaboration to be terminated before the company entrusts the partner with critical systems and a multi-year budget.
A good partner hands over control
The CIO remains in charge of the architecture, data and risk-related decisions. The partner may advise and implement, but should not be the only party with an understanding of the environment, nor the sole source of information regarding its costs and quality.
From the board’s perspective, the most important factors are the expected business outcome, acceptable risk, total cost and the ability to change suppliers. The choice of a specific technology is of secondary importance to the question of whether the organisation will retain control over its environment.
The best partner does not offer the widest range of technologies. It simplifies the environment, mitigates risk and prepares the client to operate independently.
A modernisation is truly successful when, upon its completion, the company has greater control over technology, costs and business continuity than before.
