Oscar Renalias

Navigating the Challenges of Large Enterprise Transformations

Enterprise transformations matter. They are a how organizations respond to cost pressure, modernization needs, speed, or at times, survival. However, large enterprise transformations are rarely linear. Plans will change, assumptions will no longer hold true and risks will eventually materialize. If you’ve led or been part of large migrations, you already know this.

Ambition does not separate successful programs from stalled ones. Discipline, consistency, and rigor do.

The following observations are based on patterns (“challenges”) I’ve seen over the years, and the practical measures that transformation leaders and practitioners can put in place in order to make a difference.

The Challenges

Transformations are a Joint IT and Business Endeavour

Successful transformations must be driven as collaborative efforts between IT and business units.

If a transformation can be driven as purely as an IT program, it means that it’s not driving value for the business like cost savings or faster time to market. Conversely, a business-led transformation without IT involvement means that the organization is dominated by shadow IT and that business does not trust IT, generating silos and security risks. Both extremes, and anything in between, are signs of deep strategic flaws, misalignment around strategies, dooming the transformation.

Transformations are unequivocally joint exercises demanding sponsorship and support from both business and IT leaders. Without this commitment, IT will fail to deliver business value, while business-only initiatives will only increase the rift with IT and erode organizational trust.

Business wants speed and innovation, IT wants predictability and compliance. We can have both while still delivering on the expected objectives of a transformation.

Cloud Migrations

Cloud migrations stall when discipline is missing, not when technology is lacking.

Three big issues stand out: inconsistent methods across teams slow everything down and block cost savings, like missing out on shared efficiencies; missign or incomplete lists of apps that work as the source of truth and that can answer basic questions such as how many apps do we have? who owns them? where are they running?, this lead to wrong plans, overlooked links between systems, and big delays; and staff pushback creates friction, extra costs, and hold-ups that drag on for months.

The fixes are straightforward and work if addressed early on in the transformation. Set up one consistent migration approach with clear steps methodology and tooling that works for all required strategies (such as rehost, refactor, redeploy, retire, etc.).

If internal teams lack skills or capacity, bring in a partner with enterprise-scale experience to help with the transformation. Build an inventory of applications (as a single source of truth), make everyone work out of it, keep it up to date, and standardize the methodology to drive repeatable and predictable results.

Stakeholder Alignment and Strategic Planning

Lack of stakeholder alignment and poor strategic planning are critical factors that stall transformations.

The biggest transformation failures I’ve seen were not technical. They were governance failures at executive level.

Get business and IT executives to sponsor and govern the transformation together. This forces joint ownership and keeps everyone committed. It aligns business goals like growing revenue with IT work like building scalable cloud systems. Use shared metrics—such as migration speed and cost savings—to hold teams accountable and keep things moving.

Organizational friction and politics are also key areas to address as part of alignment. Proactively address friction through clear joint messaging. A robust strategy, co-developed with stakeholder input, standardizes approaches and inventories apps for dependency mapping. Alignment across the organization not only accelerates progress but delivers clear results, significantly contributing to success.

Skill Gaps to Execute and Sustain the Migration

Skill gaps in the workforce can massively slow down transformation, and limit its benefits later.

Cloud, security, governance, and cost control require different skills than running legacy environments and old applications. Most organizations don’t have those skills at scale when they begin.

So, what are the options?

Upskill the current workforce

This is the most sustainable path. Your existing teams understand the systems, the history, and the internal politics. But don’t underestimate the effort required to upskill a large part or even the entirety of the enterprise; it takes time, and during a live transformation, time is limited. However, what you get at the end of the training are trained resources, which is far from expert resources; the gap needs to be filled with the next two options.

Hire from the market

Bringing in experienced cloud architects, security specialists, or FinOps leads from the market that can make immediate impact on the transformation. The challenge is cost and availability. The profiles you need are in high demand, and hiring alone rarely scales fast enough for enterprise-wide change.

Work with a transformation partner

Large-scale transformations often require skills and delivery capacity that simply do not exist internally at the start. Large system integrators, like Accenture, have entire organizations dedicated to cloud migration with expertise, scale and accelerators that can bring structured migration factories, predefined cloud landing zone patterns, security blueprints, governance models, and industry-specific accelerators that would take years to build by yourself. That’s important when you are trying to transform hundreds of applications.

The risk is, however, dependency. Ensure that your resources work very closely with your transformation partner, your internal resources need to “soak up” the methods, decision logic, constraints, and trade-offs behind the solutions, and not just observe and review the outputs at the very end.

Also, do not allow the partner to operate as a detached capability. It must be a partnership, not a customer–supplier relationship, where accountability for outcomes should be shared. When ownership is joint, knowledge transfers naturally. When ownership is outsourced, capability leaves when the contract ends.

In practice, most large transformations require all three. Upskill to build long-term capability, hire selectively for critical roles, and use partners to create capacity and structure during intense phases. Ignoring any one of these typically creates either delay, overspend, or long-term capability gaps.

Transformation Governance

Most large transformations fail because of unclear ownership and weak decision-making, not because of technology.

Transformation governance is about who decides, who is accountable, and how conflicts are resolved throughout the transformation. If there’s no governance at all, or if any of these three key areas are not addressed, the likelihood of failing the transformation will increase.

Clear decision and processes

Define upfront who owns scope, standards, prioritization, and budget.

If every major decision requires broad consensus, nothing moves. No one likes to sit in endless boring steering committees and operational boards.

People need to be empowered to make decisions, at their level of competence, but through formal governance structures. When decisions are made informally or outside agreed forums, alignment erodes and execution slows.

Record and communicate decisions

I have been in too many steering committees where the same topics resurface month after month because prior decisions were never properly captured or communicated. When decisions are not written down and shared, they get reinterpreted, challenged, or quietly ignored.

Governance only works if decisions are documented and communicated clearly. Every major decision should be recorded: what was decided, who decided it, what assumptions were made, and what the implications are.

A simple decision log, accessible to all workstreams, prevents this drift. Governance is not just about making decisions — it is about making them stick.

Disciplined escalation

Steering committees are decision forums, not reporting sessions. If meetings revolve around slide decks instead of decisions, governance becomes decorative instead of operational. When escalation paths are unclear, issues do not get addressed that that impacts progress and value realization.

Strong governance reduces noise, shortens decision cycles, and keeps the program aligned when pressure increases. Weak governance does the opposite.

Measuring Transformation Success

Every transformation starts with a business case. Very few are managed against it.

Personally, I have yet to see a large transformation approved without a business case: cost savings, agility, faster time to market, modernization, and many more relevant levers tend to be part of the business case. It helps clearly articulate the objectives of the transformation in a data-driven and tangible manner.

A business case also helps ensure that we do not measure success by the number of apps migrated or transformed, but that we measure the right business outcomes.

Typically, the problem is not the absence of a business case. The problem is that often, once the program begins, it is rarely maintained. Assumptions change. Scope shifts. Benefits get reinterpreted. And too often, no one is clearly accountable for tracking whether the original value is still achievable.

If the business case is not actively monitored and owned, success becomes subjective. Technical milestones get celebrated while financial or operational benefits quietly drift.

A transformation should be measured against the value it promised to deliver. That requires a named owner for the business case, regular benefit tracking, and the willingness to adjust when reality diverges from initial assumptions. When the business case is actively managed, demonstrating value becomes straightforward. When it is not, value becomes a matter of opinion and it is very difficult to argue on the basis of opinions.

Change Management

Change management is an ongoing process that should be integrated into every stage of the transformation journey.

Implementing change management practices early is essential for organizations to align stakeholders and clarify expectations – we must all have the same understanding of the transformation and its objectives after all.

Change should be a structured workstream with executive sponsorship, ownership, and metrics. Practical measures include:

• Nominate transformation change managers per group/unit/business
• Running joint IT–business town halls or events to reinforce purpose and progress; I’ve been in programs where senior leadership would only get involved in steering committees and decision boards with a very small audience, and never showed their face in major townhalls or program events. Don’t be that kind of leader.
• Communicating with impacted organizations and resources, help them understand how their daily work will change. Not knowing what the future looks like, the threat of having your current job removed can have a very negative impact on people.
• Tracking adoption KPIs alongside technical milestones to ensure that the change is being managed well and is in sync with the delivery

Conclusion: Embracing Transformation

As a technologist, and as someone who naturally belives that technology typically can most problems, I’ve observed over the years that the difference between failed transformations and successful ones is rarely technical brilliance. It is clarity of ownership and disciplined execution. Technology is an enabler, ownership and execution determine whether it delivers value.

Clarity of ownership means knowing who is accountable for outcomes. It means that business and IT sponsodinr the transformation together, that decisions decisions made in the right forums and recorded properly, and that partners working with you, not instead of you. When ownership is vague, no one knows who is accountable for what, responsibility is too spread out and value is not delivered.

Disciplined execution means doing the basics consistently: enforcing a standard approach and methodology, investing in skills, and measuring adoption not just pure delivery. None of this is rocket science (we’re talking aobut the basics after all), but it requires consistency and sustained leadership.

Changelog