Hard-Learned Lesson: Don't Forget the Data in Application Migrations

Loraine Lawson

Data is one of those tiny details that's easy to forget when you're switching to a new system. Informatica CIO Tony Young says it's the cause of most ERP failures and "one of the higher-risk components of any type of application project."

 

It's so tricky, even Informatica-whose very focus is data-mishandled the data portion of a legacy cost center application back in 2001, Young reveals in a recent Forbes interview.

 

Informatica hired a large systems integrator to help with the application change. Like many other companies, it was so focused on the new system running, it forgot the data:

Like a lot of these engagements, one of the afterthoughts of the engagement was the data. Most companies focus on getting the system configured based on the business requirements.


The systems integrator wanted to charge 20 percent more to migrate the data. Informatica was a pure-play ETL vendor at the time, and though it was focused on data warehousing, Young realized it could use its own tool for the migration. Oddly, Informatica's then-CEO was not interested in how using the tool for legacy migration and data integration could affect Informatica's business model:

When I went to the CEO with this idea, he said, 'That's a non-standard use of our technology. We build data warehouses.' The mindset of the company at the time was to move data from legacy systems and into data warehouses. When we got a new CEO five years ago, he said, 'We're a data-integration company.' So for the past five years we've been focused on data integration.

 

Perhaps you can take some comfort in knowing even pros get it wrong. But I wouldn't laugh too fast, because the odds are stacked against you when it comes to data migration, according to Swati Ranganathan, a senior program manager at LAM Research.

 


Ranganathan is writing a blog series on the challenges of data migrations. In a recent post, he shares some disconcerting statistics he's uncovered about data migrations, (although, I should note he doesn't provide specific sources, so they could be dated):

  • 84 percent fail to meet expectations.
  • 37 percent experience budget overruns.
  • 67 percent are not delivered on time.

 

He includes a list of reasons why data migrations fail, and in the second post, he addresses common misconceptions about data migration. One theme that's common to the both posts thus far: Debunking the idea that data migration is "just" IT's job or is only about moving data:

Often project teams tasked with data migration focus solely on the timely conversion and movement of data between systems. But data migration is not just about moving the data into the new application; it's about making the data work once within the new application. This means that the data in the new application must be accurate and trustworthy for business users to readily transition from their legacy applications to adopt this new application.

 

Arthur Cole made a similar point in a 2008 post on his IT Business Edge Infrastructure blog:

Some of the main stumbling blocks to a successful migration are not technical, but organizational. If there is one universal rule of thumb, it's that the process goes a lot more smoothly if data users are involved.


If Young and his team hadn't taken a creative approach to the problem, Informatica would have paid a high price - a 20 percent markup on the project - just because they forgot to address the data migration from the get-go.

 

There's a good chance companies could be relearning this lesson the hard way as they move applications to the cloud. Already, much of the discussion of the cloud pays little heed to how using cloud services will affect the data.

 

Don't be one of them. Make dealing with the data an early step in any application migration.



Add Comment      Leave a comment on this blog post
Jul 15, 2009 5:40 AM Francis Carden Francis Carden  says:

If I take my car and break all the parts down into individual pieces and place all those pieces in a big box, is it still a car? Could someone who does not know how my particular car is put together, take all of the pieces of the the box and re-build my car without a spec? Pretty unlikely, right? It'll always be a box of worthless parts.

That's what DATA is. On it's own, Data is a series of parts that is mostly meaningless without the business logic to describe it in perfect detail (anything less than perfect is highly risky) - hence the high path top failure percentages above. This also explains why, in 2009 and the same will be true in 2019, most data is part of some legacy system, that stands behind millions of man years of code. The legacy application is key. The Data, well it's just a part!

Reply
Jul 15, 2009 9:38 AM Luong Le-huy Luong Le-huy  says: in response to Francis Carden

I only agree with Francis to 50 percent.  What he said is certainly true for "silos" systems, but not for 'real' 3-tier architecture, where data and databases are constructed in proper manners, completely independent from applications. In the second scenario, data will make sense by itself, hence applications can come and go, but data can stay forever.  Data migration or integration would not be an issue. They won't even exist!

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.