Real Time Insights and Cloud Transformation: What Actually Changes When You Leave Legacy Behind

Your legacy system works. That’s the problem.

It works well enough that nobody wants to touch it. The month-end close happens. Reports get produced. The board pack lands on time, mostly. And so the conversation about real time insights and cloud transformation keeps getting pushed to next quarter, then the quarter after that.

But “works” is doing a lot of heavy lifting in that sentence. What you actually mean is: six people spend four days producing a board pack that’s already stale by the time it’s presented. Your FP&A team spends 70% of their time gathering and reconciling data, not analysing it. And when the CEO asks a question that isn’t in the standard reports, everyone scrambles.

That’s not working. That’s surviving.

The Real Cost of “Good Enough” Legacy Systems

Here’s what legacy finance systems actually cost you, beyond the obvious maintenance fees and the consultant who retired in 2019 but still gets called when something breaks.

A £200M fintech we worked with had their finance team running three separate planning processes. One in their on-premise EPM tool, one in a collection of Excel models that had grown organically over eight years, and one in the heads of two senior analysts who knew where all the bodies were buried. The official system was the EPM tool. The actual system was whatever combination of the three got the answer fastest.

Their CFO estimated they were spending £400,000 annually on a platform they’d essentially abandoned. Not because it was bad software, but because it couldn’t keep pace with how the business had evolved. New product lines, acquired companies, changed reporting requirements. The system that was perfect in 2016 had become a constraint by 2024.

This is the pattern we see repeatedly. Legacy systems don’t fail dramatically. They fail slowly, through workarounds. Every workaround is a small admission that the system can’t do what you need. Stack enough workarounds and you’ve built a shadow system that nobody officially acknowledges but everyone depends on.

The finance team knows this. They’ve been saying it for years. But the business case for change is hard to make when the current system technically still functions.

What Cloud Actually Gives You (And What It Doesn’t)

Cloud transformation has become one of those phrases that means everything and nothing. Vendors throw it around like it’s a magic spell that solves all problems. It isn’t.

What cloud EPM platforms genuinely deliver is architectural flexibility. Your data model can evolve without a six-month development cycle. New entities, new hierarchies, new reporting dimensions can be added in weeks rather than quarters. That matters when you’re growing, acquiring, or restructuring, which is to say, always.

Real time insights become possible, not automatic. The technology enables it. Whether you actually get real time insights depends entirely on your data integration, your process design, and whether your team knows what questions to ask. We’ve seen cloud implementations that deliver worse reporting than the legacy system they replaced, because nobody thought about what “real time” actually meant for their business.

“The platform is never the problem. The problem is always what happens around the platform.”

A Lloyd’s syndicate we implemented for understood this distinction. Their COO made a deliberate choice to treat the cloud migration as a process transformation project that happened to involve new technology, rather than a technology project that would somehow fix their processes. They spent more time on data governance and workflow design than on platform configuration. Eighteen months later, their actuarial team could run scenarios that previously took days in under an hour.

But here’s what cloud doesn’t give you: it doesn’t give you clean data. It doesn’t give you agreed definitions. It doesn’t give you a finance team that suddenly has time to analyse instead of gather. Those problems travel with you to the cloud. They just become more visible.

The Migration Nobody Talks About

Every cloud transformation has two migrations. The technical migration, which vendors love to discuss, involves moving data, rebuilding models, configuring integrations. This is the part with project plans and go-live dates and celebration emails.

The other migration is cultural. It’s the shift from “we run reports” to “we answer questions.” From “the system can’t do that” to “let’s build it.” From monthly cycles to continuous insight. This migration takes longer, costs more, and fails more often than the technical one.

A PE-backed SaaS company we worked with last year completed their technical migration in fourteen weeks. Impressive by any standard. But six months later, their finance team was still producing the same reports on the same schedule they’d always used. The cloud platform sat there, capable of real time insights, while the team exported data to Excel because that’s how they’d always done the analysis.

The platform wasn’t the constraint anymore. The habits were.

This is why we sometimes tell clients they’re not ready for cloud transformation. Not because their systems are too old or their data is too messy, though both might be true. Because their organisation hasn’t done the harder work of deciding what they actually want from their finance function. Moving to the cloud without answering that question is expensive displacement activity.

What Real Time Actually Means for Finance Teams

“Real time” is another phrase that’s lost all meaning through overuse. For finance, it needs a specific definition or it becomes a buzzword that justifies any spending.

Real time insights in finance typically means three things. First, you can see current performance without waiting for month-end. Your revenue, your costs, your cash position, updated daily or more frequently. Second, you can run scenarios without a two-week turnaround. What happens if that deal closes? What if it doesn’t? What if we accelerate hiring? Third, you can answer questions you didn’t anticipate. The board asks something new, and you can respond in the meeting rather than taking it away.

None of this requires cloud technology. You could theoretically achieve all of it with on-premise systems and enough integration work. But cloud makes it economically viable for mid-market companies in a way it wasn’t before. The infrastructure cost that used to require £2M+ investment is now a subscription. The integration complexity that used to require a dedicated team is now handled by pre-built connectors.

For a £50M manufacturer we advised, the real time capability they actually needed was simple: daily visibility into production costs by product line. Their legacy system could produce this, but only through a manual extract that took their cost accountant half a day. In their new cloud environment, it’s a dashboard that updates automatically. Same insight, radically different effort to obtain it.

The transformation wasn’t about sophistication. It was about removing friction from something they were already trying to do.

The Integration Question Everyone Underestimates

Your EPM platform, whether cloud or legacy, is only as good as the data flowing into it. This is obvious. Everyone nods when you say it. And then they underestimate integration complexity by a factor of three.

Legacy systems often have integration patterns that evolved organically over years. Data flows that nobody documented. Transformations that happen in intermediate staging tables that someone built in 2017 and forgot about. When you move to cloud, all of this needs to be understood, replicated, or redesigned.

We’ve seen twelve-week implementation projects stretch to eighteen months because the integration work was scoped based on what people thought was happening rather than what was actually happening. The discovery phase found data transformations that weren’t in any documentation. Source systems that had been modified without updating downstream consumers. Business logic embedded in ETL jobs that nobody could explain but everyone depended on.

This isn’t a failure of planning. It’s a feature of how legacy systems accumulate complexity. Every quick fix, every workaround, every “we’ll document this later” becomes technical debt that comes due during migration.

The companies that handle this well are the ones who budget for discovery as a distinct phase. Not a week of workshops, but a proper forensic examination of how data actually moves through the organisation. It feels like it slows down the project. It actually prevents the project from failing.

Making the Business Case When “Good Enough” Is the Enemy

If you’re reading this, you probably already know your legacy systems need to change. The challenge is making the case to people who don’t live with the daily friction.

The CFO who approves the budget sees reports arriving on time. The CEO sees a finance team that delivers what’s asked. The board sees numbers that reconcile. From the outside, the system works.

Here’s what we’ve seen work for making the case. First, quantify the workarounds. Every hour your team spends on manual reconciliation, on maintaining shadow Excel models, on explaining why the numbers don’t match, that’s cost. It’s also opportunity cost, time not spent on analysis that could actually improve decisions.

Second, connect to strategic constraints. Is the business planning an acquisition? Your legacy system probably can’t integrate a new entity quickly. Expanding into new markets? Your reporting dimensions are probably hard-coded. Planning for exit? Your buyers will want data quality that your current systems can’t demonstrate.

Third, be honest about risk. Legacy systems don’t just constrain growth. They concentrate knowledge in people who might leave, depend on vendors who might discontinue support, and create single points of failure that become more dangerous over time.

A £300M retail business we advised made their case primarily on risk. Their core planning system ran on infrastructure that was approaching end-of-life, supported by a vendor who had been acquired twice and was clearly deprioritising their product. The transformation wasn’t about new capabilities. It was about not being held hostage by a dying platform.

The Honest Timeline for Transformation

Vendors will tell you twelve weeks. Consultants will tell you six months. The truth is somewhere between nine months and two years, depending on your complexity and your ambition.

The technical implementation, getting the platform configured and integrated, typically takes three to six months for a mid-market company. That’s the easy part.

The process redesign, changing how your team actually works, takes another six to twelve months. New workflows need to be designed, tested, refined. People need to learn new tools and unlearn old habits. The organisation needs to adjust its expectations about what finance can deliver and when.

The cultural shift, moving from report production to insight generation, takes longer still. Some organisations never complete it. They end up with cloud platforms running legacy processes, which is better than nothing but far short of the potential.

If someone promises you transformation in twelve weeks, they’re either defining transformation very narrowly or they’re setting you up for disappointment. Real change takes time. The question is whether you start now or keep pushing it to next quarter.

---

The uncomfortable truth about legacy finance systems is that they’ll keep working until they don’t. The month-end will close. The reports will get produced. And then one day, the CEO will ask a question that requires data you can’t get, or an acquisition will require integration you can’t do, or a key person will leave and take irreplaceable knowledge with them.

Cloud transformation isn’t about chasing technology trends. It’s about building a finance function that can evolve as fast as your business needs it to. The companies that start this journey before they’re forced to have options. The ones that wait often don’t.

If you want more perspectives on finance transformation from people who’ve done the implementation work, not just advised on it, connect with us. Bolt Blueprint can help demystify the art of the possible!