According to IDC, 38% of enterprise cloud migrations exceed the planned budget, and one in three projects misses deadlines. Companies migrate monolithic systems to cloud platforms in the hope of reducing infrastructure costs, but in a year they receive a bill that is higher than what they would have on their own servers.
According to IDC, 38% of enterprise cloud migrations exceed the planned budget, and one in three projects misses deadlines. Companies migrate monolithic systems to cloud platforms in the hope of reducing infrastructure costs, but in a year they receive a bill that is higher than what they would have on their own servers.
Mykhailo Krasovsky, Lead Solution Architect at Trinetix, has been working with corporate systems for over 18 years and sees one of the reasons for such failures in the choice of architecture: in recent years, he has been leading projects for one of the Big Four companies in the field of auditing and consulting, whose clients include Fortune 500 and S&P 500 companies.
In particular, Krasovsky was responsible for migrating a large corporate product from its own server infrastructure to cloud microservices on the Amazon Web Services platform and managed to reduce hosting and operational costs by a third, while accelerating product update capabilities. dev.ua spoke with Krasovsky about why cloud migrations don’t go according to plan and what distinguishes an architectural solution that works from one that only looks right on paper.
Cloud migration is the second-highest priority in the Gartner CIO Survey in 2026, behind only cybersecurity. However, in many companies, Krasovsky says, migration begins with choosing a cloud provider and agreeing on a budget — before the architect has a chance to analyze the system — and this is why cloud projects fail to deliver the expected savings.
Moving a monolithic system to the cloud, as his experience with large projects has shown, does not solve anything in itself — along with the code, overloaded processes and architectural limitations that have accumulated over the years move. The cloud provider does not optimize what it receives — it charges for it.
«When I enter a project like this, the first thing I do is try to turn the conversation back to architecture as early as possible,» says the expert. «Until there is an understanding of how to break down the system, any decision to move is a choice of tariff, not an architectural decision.»
In large products, the development of which Krasovsky led, a significant problem with monolithic architecture is the inability to scale high-load components separately from the entire system. In the cloud, this translates into direct costs: the provider charges for all allocated capacity, even when 80% of the load falls on one component out of ten.
The first question Krasovsky asks in such projects is how to divide the system into independent parts. It is this decision that determines the cost of the cloud per year. According to him, the same limitation also held back the team’s pace:
«Teams were focused on the architecture before the task. You can’t accelerate the release of new functionality if the entire system is only updated as a whole,» he explains.
In one of the migration projects, for which Krasovsky was responsible as the architect of the entire system, this approach made it possible to reduce the cost of maintaining the product by 30%. The project involved decomposing a monolithic product into microservices and switching to the Amazon Web Services infrastructure.
Krasovsky believes that the main result for the business is the ability to implement new functionality faster — from idea to implementation. After switching to microservices, teams stopped waiting for each other, which increased the speed of releasing new features by 2.5 times.
«It didn’t happen by itself. We immediately designed the services so that each could be deployed independently. If this is not included at the stage of monolith decomposition,» says the expert, «microservices will turn into a distributed monolith with the same problems or even worse.»
Krasovsky developed this approach to architecture long before working with a Big Four company. As part of the OpenText team, he participated in the development of a business process management system used by Fortune 500 companies. He now also leads the architecture practice at Trinetix, where he coordinates the work of 50 architects and standardizes approaches for large enterprise projects. According to Krasovsky, working with enterprise systems changes the way you look at development: architectural decisions are made with business implications in mind.
«When tens of thousands of employees use a system, you stop thinking only about the features. You start thinking about how much each subsequent change will cost or what will happen if a critical service goes down on the Friday night before the financial period closes,» he says.
And he emphasizes that architecture has already become a long-term risk management tool for large companies. It determines how much a business will cost to develop a product and whether it will be able to avoid infrastructure crises.
