"I skate to where the puck is going to be, not where it has been."

-  Wayne Gretzky

I love this quote from Wayne Gretzky. It sums up how most organizations approach data strategy.

Data strategy typically starts with a strategic plan laid down by the board. The CEO will have a grand vision for a future business model or direction for the organization and this is subsequently broken down into strategic plans for each major function within the company. So the whole organization (in theory) tries to "skate to where the puck is going to be" by aligning people, process and technology toward this future vision, the classic "PPT."

As data professionals, we mostly get involved with the 'T' aspect of this acronym because data strategy typically involves some form of IT transformation.

Perhaps your business model is adapting to include wholesale and retail consumers, or maybe the CEO wants to extend the model to service B2B customers as well as your traditional B2C base. Whatever the change, systems and information will undoubtedly need to be extended or replaced to cope with the grand new vision.

A transformation plan will be drawn up – and somewhere, buried deep within the work breakdown structure, is a step marked system migration.

Understand migration

System migration is a seemingly innocuous action that is often deemed IT-centric by business leaders but is in fact deeply reliant on assistance from all levels of the company. Migrating systems to support a data strategy requires extensive data migration work. Data migration is often where the overall corporate strategy starts to falter and the shockwaves of this delay are often felt all the way up the hierarchy to board level.

At one organization I consulted with, the company spent millions of pounds and many years without migrating a single item of data. Their strategic plan drew to an embarrassing halt as they struggled to battle through endless data migration obstacles.

The problem is that the very people responsible for data strategy, the C-level executives, completely underestimate the complexity of migrating systems. It is a task that is often outsourced, under-resourced or under-planned. The results are predictable. Lengthy delays or outright failure.

So how can you align your data migration to the strategic goals of the organization and keep the project on track?

Over the coming weeks, I'll share some practical ideas. But in this first post, I want to focus on the first task required for successful data migration: Knowledge gathering.

To "skate to where the puck is going" with your IT architecture, you need to (obviously) have a clear picture of where you are and where you are heading. Sadly, most companies have a sketchy view of both.

Know the legacy

Legacy understanding tends to be the biggest failing. At one organization, I discovered they had no knowledge of what systems made up the legacy environment, let alone what data existed there! All this, despite having an aggressive corporate data transformation in place.

So, if you are responsible for implementing a data strategy this year, you need to ensure your teams are doing one thing right – understanding the legacy environments that drive current business.

What you will find is that the knowledge of your legacy landscape is not as accurate as first perceived. You will invariably discover undocumented databases and local spreadsheets. There will be conflicting and overlapping data areas with plenty of turf wars and battles for data ownership.

Those building your data strategy need to understand this legacy environment before implementing the strategy. You need this feedback to gauge the pace at which your IT transformation can take place. Just as important, you need to understand the quality of your legacy data, because this will directly influence future strategy.

For example, one utility director was horrified to discover that a key data item, crucial to his future business model, was 90% incomplete. This knowledge helped the utility put new measures and processes in place that would collect the data and help keep the new strategic plan on track. Without this legacy knowledge, they would have hit a serious roadblock when the time came to roll out the new IT architecture.

Action points:

• Go through your data strategy and identify what system or business function transformations are expected.
• Examine whether steps are being taken to gather legacy knowledge of the core data used in these transformations.
• Ask if these knowledge gathering exercises are comprehensive. Get a third-party opinion on any discovery and data quality steps that are on the plan.

In the next post, we'll explore how data migration drives data strategy, and I'll provide some pointers on how to avoid common data strategy mistakes.