2020-02-17 - Data Migration Subgroup Agenda and Notes

We will meet for a half-hour to hear updates the migration efforts of our members.

At ByWater they started migrating inventory. It was a little frustrating. (Ian Walls can you work these notes out ??)

A clever solution to generate persistent UUIDS. There are 5 versions. Version 4 assigns a random UUID. 4+5 = hashing a given string (MD5 e.g.). Using an algorithm instead of a map. "This legacy ID converts into this MD5 id". Not having a bunch of mapping tables. Better solution to fix UUIDs for this migration. Use different UUIDs for the next migration. .. There are no performance issues using this hash.

UUIDs are created outside of FOLIO and then inserted, but are still guaranteed to be unique. No collision between auto-generated values by Folio and generated values during migration. Because one used Version 4, the other version 5.

From Jenn Colt: One thing out of the erm migration - if you give it your own UUIDs, it will throw them away. It would be good if all the modules let you give your own UUID. Licenses in erm I mean.

For migration from Voyager TAMU has a second database. We keep all our references there, the matches to UUIDs. You have to maintain a 2nd database. In Chicago, they do something similar. Chicago generated their SRS data externally and wrote that back to their database. Downside is, you have to do your MARC mapping on your own.

At Lehigh, all MARC records were loaded to source record storage. Chris Creswell worked on that.

Matt: Started with index data hosting.