Skip to Content

For background on data migration, check out Ginger Gatling’s blog (First look at SAP’s Data Migration Solution).

As Ginger points out, our data migration offering centers around an SAP customer who’s migrating data into an SAP system AND current customers who are bringing in new plants, new business units, etc., and need to migrate data to an SAP system.

data migration

To complete your migration project successfully (on time, without drama), you absolutely NEED a thorough understanding of your data. In fact, you need this information up front, to help you even estimate how long your migration project should take to complete.

In How to get started with Information Governance, I talked about what information governance is, and how starting on a smaller, tactical project is a best practice. Guess what? Data migration is a excellent tactical project with which to start. In this blog, we’ll discuss how to apply information governance principles and how you can scale your work products to future information governance initiatives.   

Information governance basic principles follow:

  • Identify the critical data elements. This indentification requires you to understand the data elements required in the migration target system. After you have discovered this key information, WRITE IT DOWN. Now you have not only the start of a data inventory, but some key metadata (criticality) assigned to data elements. Yes, you’ve started creating data policies. Try to contain yourself…it gets better. (SAP BusinessObjects Information Steward can help with this process.)
  • Quantify how managing those data elements increase value. You don’t have to go overboard and get super precise here, but these basic definitions of value will help you build metrics that show the success of your program. These metrics can be used in future projects to help you build service level agreements with both internal and external stakeholders.
  • Establish a current baseline for those critical elements. In Quantify, we talked about determining value. This step determines what level of fit-for-use your data is currently conforming to. Without this step, you can’t pragmatically decide how far to go with your data management efforts–not only for this project, but for your next project, too. Obviously, this information will directly drive your project time estimates. (SAP BusinessObjects Information Steward can help with this process.)
  • Create an improvement plan. With the great fit-for-use policies defined in the above steps, you can create a specific, value-driven improvement plan for critical data elements. How can you develop a reasonable improvement plan? See the next bullet. ๐Ÿ™‚
  • Align Business and IT behind enterprise data standards, policies, and processes. The improvement plan developed above depends on buy-in across business and IT as to the specific business rules and policies that can be referenced in implementation. The alignment implies, too, that ownership for data domains or specific data elements are also assigned. Many times, in a tactical project like this one, the ownership is defined very informally. Take these informal decisions a small step farther–WRITE IT DOWN–and voila! You’ve established data ownership policies. these policies can definitely be leveraged in future projects. After all, your group has already determined that these are critical, high-value data elements. And you’ve defined fit-for-use qualities. Re-use this newly-gained knowledge as much as possible by documenting the data ownership. (SAP Data Migration Services can help you with this step.)
  • Define and control the full data lifecycle (definition to destruction). For data migration, you can go light on this step, because your immediate concern is how to get existing data into a different system. However, as you discover the data policies/baselines/etc. we talked about above, you are bound to also uncover create, read, update, and delete (CRUD) policies around those data elements. Again, write those things down as they come up, and you’ll have a start at documenting CRUD policies.
  • Quantify results. Hey, look! You already defined a baseline and quantified value. The dashboard nearly creates itself! Now just publish your success, making sure you are doing this in terms of the business value (revenue at risk, for example) instead of low-level data characteristics (% of nulls, for example). Who doesn’t love a KPI? (SAP BusinessObjects Information Steward can help with this process.)

Now you are ready to do it again, basing your next project on what you’ve already done. Again, here is what you’ve established in your data migration project:

  • data inventory (what do you have, and where is it)
  • data policies (what data is critical, and what is fit-for-use)
  • data ownership (who takes care of specific data elements)
  • business rules (what needs to be done to transform data to fit-for-use standards)
  • CRUD policies, KPIs and dashboards to show value.

Time to get started!

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply