Legacy Data Tool Migration – Success with Operational Consistency

by Rebecca Zeus
September 26, 2024

Legacy Complexity

Businesses often underestimate the complexity of their existing data ecosystems and just how much institutional knowledge has been built into them over the years. Attempting to replace them with new technologies can lead to unexpected hurdles and higher-than-anticipated switching costs.

Teams commonly find gaps as they attempt to migrate across systems, typically because evaluation criteria focuses on features rather than business usage. These gaps prevent them from decommissioning the old system, because of business capability that is expensive to replicate in the new solution and the migration budget isn’t sufficient to cover this

A complex problem can still have a simple solution.  When the data ecosystem is not operationalised, these scenarios are highly likely.  Whereas having a solid understanding of your data ecosystem and established operational consistency, you can more readily map the migration and either improve your system selection or make other arrangements to bridge any foreseen (and unforeseen) gaps.


The “Silver Bullet” Fallacy

Consider a scenario where a legacy system that manages customer data is intricately connected with various business processes. A hasty migration to a new solution might disrupt these connections, leading to operational bottlenecks, manual intervention, offline workarounds and higher costs.  Sometimes the disruptions are significant enough that the business may end up running – and incurring costs for – both systems for much longer than anticipated.

A Tale of Two Systems

Many times, migration off the legacy systems never happens completely because the business is reluctant to remove some workloads from trusted systems. Both are kept in play and the business incurs the costs to run and maintain both the partially implemented new technology and the legacy system it was intended to replace.

When another new tool or process is introduced, fixes and changes may need to be applied to both systems. Data integrations must take both systems into account. Troubleshooting a problem or failure takes extra time, energy and money – which can become critical if the problem is significant such as a data breach or other crisis. Running dual systems – one of which is older and possibly no longer patchable – contributes to security and governance vulnerabilities, risking further capacity and financial loss.

Mind the Gap

Sometimes there is a business directive to deprecate the legacy system regardless of these gaps and issues, to avoid continuing to pay for both systems.  This results in a considerable amount of untracked offline work, manual interventions and workarounds, to bridge the gaps between the systems and maintain “business as usual”.  Once the project has ended and the capital budget is closed out, these issues become the problems of daily operations.


Solution – Get Operational, Map & Plan

BizCubed’s approach is premised on the belief that data transformation, system migration and digital modernisation can be improved by building better organisational habits, and that operationalising repeatable, scalable patterns is a more efficient route to optimisation than expensive consultations and sweeping overhauls.  We leverage a “can-should-did” operational approach on top of our data engineering model.

Understand your data ecosystem

Start by mapping your processes, from inputs through to outputs: workflows, data pipelines, actions, security, governance, SLAs, and the systems to which the input and output data are connected.  Understand and document what “can” and “should” be happening.

Establish operational consistency

When you establish what you “can” and “should” be doing, you can start keeping track of what you actually “did”.  Make sure you capture everything, from the daily routine activities to the one-offs, to ensure that you truly understand the full scope of how you use the system.  Routine activities should have known procedures that are documented and repeatable.

Map the migration

Identify what your existing “can-should-did” will look like in the new system.  Map every “can” and “should”.  With any gaps that remain, understand how you will handle that – do you need to find a different target system? will you run both systems in parallel?  is there another system that can handle those gaps? Maybe you don’t need to migrate it to the new system, because the data already exists in, and will remain available in, your existing data ecosystem.

Our method of applying our data engineering methodology is a comprehensive approach that leverages an organisation’s existing resources – including its legacy systems and tools – you win back capacity, reduce risk, and deliver better outcomes. Once an organisation has an operationally consistent base upon which to continue to invest, they can leverage new technology and innovate.

Your business is likely to have a variety of tools that evolve and change over time. New investments will one day too become legacy. Your data team’s capability must be flexible enough to match, and robust enough to optimise as many use cases as possible.

Ensure your business and IT teams work together to understand what “can” and “should” happen. In doing so you can simply get on with the important work of enabling your business to out-compete with data even as you maintain “old” systems and deploy new technology.

Portrait of Maxx Silver
Rebecca Zeus

Rebecca Zeus is Co-CEO and Director of Sales at BizCubed. A chemical engineer by training and a Lean Six Sigma Blackbelt, she has built a reputation as an expert in process design and implementation. Most recently, she led a company-wide initiative to formalise and certify BizCubed’s Information Security Management System. She is also a mother of four, an avid volunteer, a non-profit board member, and a crafting-enthusiast.

More blog posts