Loading History into LTM

We didn't do it from S3, since we implemented S3 and LTM at the same time.  We did load history into LTM from our legacy system.  It is possible, but it is pretty ugly to make it happen because of the "As Of Date" features of Landmark/TM.  We did this in mid-2010, so some things have changed.

For a little background, what we call "history" is what the application calls the "audit log", and it is really focused on keeping track of who did what to a specific record and what changed, rather than being focused on storing point-in-time employee history.  This is a small but very important difference, which explains why most HR folks really, really don't like how this is stored in TM.

History is accessible via the application, but it is very difficult (read "impossible") to access for any other use - such as reporting. It is stored as xml in a CLOB field on the record which stores the effective date, actor, and what the old and new values are for the fields that changed - which is very tough to deal with. We've actually had to have one of our ace DBAs pull the data out of the database and parse the xml into tables we can use for reporting, but even this is very difficult to use - not something that would be usable to most analysts, let alone end-users.

Unfortunately, your HR team will not be exited about how this looks in TM, but you really don't have much choice if that will be your system of record.

Here are a couple of things to be aware of on the history load:

• Data setup is key.  In order to load history, all of the data items have to exist for the dates you are trying to load - i.e. all locations, jobs, positions, org units, etc., etc., etc. have to exist with an as-of date on or before the earliest date you will be load to it. When we did it, we loaded all of our "legacy" objects with a 1/1/1935 date (since that was the "beginning of time" for our company). After our history load we then disabled all those old objects and created new objects for ongoing use - which may not work in your situation.
• History is loaded by business class, so Employee Master, Work Assignment, Address, Phones/Email, SSN, etc are all loaded separately, but are dependent (i.e. Employee must be loaded first (after jobs, positions, org units, etc).
• History data must be loaded by business class in date order (oldest to newest), and you can't just "add" stuff later if you forget or screw up. Since we did our history load, they have added some ability to "fix" history, but it is really tough and makes the audit log tough to read.
• You will probably have to go through multiple "test" conversions to get all the issues fixed so the load works correctly.

As something to consider, this is what we did to make our cutover successful:

• Start with an "empty" environment and did our initial configuration of all the prerequisite setup of org units, jobs positions, etc. 
• save off that configuration data as "pristine". 
• Do our test conversion - which identified any configuration issues we needed to resolve.
• Wipe out our data and restore the "pristine" data
• Updated "pristine" to add whatever we missed and save it again as "pristine". 
• Keep repeating this cycle until everything loaded perfectly and then did our final cutover.

I hope this is helpful. 

Kelly

By the way, we loaded approx 27,000 employees using data from two legacy systems (previous system and the system before that). 

We also were very careful about what we loaded.  We only selected the data items that were really important to us.  For example, we didn't load history for gender or SSN, ethnicity or veteran status - we only loaded those with the "final" import, which was current state.  We really tried to limit this to stuff where history would really matter.

Finally, we loaded configuration settings with Spreadsheet Designer (i.e. AddIns for Landmark), but we loaded the configuration data from delimited files using command line utilities.  We loaded them into the delivered "Import" tables, and then used the import programs to get them into the "live" tables.

Kelly

Thank you. Your response is a huge help to us in determining the time and effort moving forward.


Jason

One last thing.  I did a presentation about our conversion at Cue in 2011.  Attached is a copy of my presentation slide deck.  Since we did both S3 and LTM, this is probably more info that you need, but it might be helpful.

Kelly

We are also looking to implement s3 and LTM at the same time. Our sytem test starts in the next few weeks so we've yet to see the s3 and LTM systems work together. We are having a hard time getting our Project Team to understand that HR is working on 2 different systems--each with load requirements that are a little different. Any advice on how to communicate this?

I'm surprised that your project team hasn't realized this by now. S3 and LTM are not integrated in any way - even though the sales people are good at making you think they are. With the UI changes in v10, it is harder to tell the difference than it used to be. LTM is interfaced to S3, but they truly are completely different systems.

My only recommendation is some sort of a diagram that shows the "stuff" that lives on the S3 server and on the LTM server, and how they relate.

Good Luck.

I wish someone from Infor explained all this as thoroughly as you have. I have been finding out a lot of this the hard way.