Skip to Content

Have you ever seen a new house under construction in which the living-room and dining-room are completely painted and furnished, while all the other rooms are just framed-up?

 

Then why are you doing data migration this way?

 

Shouldn’t the rules for successful construction of any complex object be the same, whether the object is the data component of SAP ERP or an equivalently expensive house? 

 

So how would you build the data component of an SAP ERP instance if you were going to do it like those know-nothing blue-collar building contractors, instead of like you’ve been taught by those super-smart IT professionals?

 

Well, you’d do it this way.

 

First you’d load the key columns in ALL your config data tables across the board , along with the columns in these tables that participate in SAP-delivered alternative indices and/or foreign key checks.

 

Then you’d do the same thing for your master data tables – just the key columns and the columns that participate in alternative indices or foreign key checks.

 

Then you’d do the same thing for your transactional data tables – just the key columns and the columns that participate in alternative indices or foreign key checks.

 

Then, after you’ve built the skeleton of your entire data component in this manner, i.e. after you’ve framed up your ENTIRE house, you’d start the sub-contractors going room-by-room to finish each room, i.e. add the rest of the data to each table.  

 

But not in any old way.  First you’d load the data that’s required by the standard SAP transactions that go against the tables, and then and only then, after you’ve finished loading all of those data, you’d finally load the data that SAP transactions consider optional.

 

Why would you want to do it this way, instead of the usual way?

 

The answer is simple, if you think about it for a moment.

 

When data migration is undertaken, virtually no one argues about where the key fields have to come from in legacy, or where the alternative index fields have to come from, or where the foreign key check fields have to come from.

 

No – the arguments are always about some relatively trivial attribute fields that aren’t keys and don’t participate in foreign key checks or alternative indices.

 

So … while the arguments are going on and on about whether such-and-such field should be 10 or 11 bytes, or whether it should contain a hyphen in the 3rd or 4th position, you’re busy “framing-up” your house by migrating the data that no one ever argues about.

Nah – it’s way too logical. 

 

And not only that, if we did it this way, we’d have to admit what everybody has always known … “there’s nothing new under the sun”, and because there’s nothing new under the sun, there’s no reason to build the data component of an SAP ERP instance any differently than you’d build a house.

 

And therefore, data engineering isn’t some abstruse branch of semiology, but actually a fairly trivial branch of civil engineering as practiced by your average general contractor who probably doesn’t even have his or her BS ….

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply