...
Este - could we also mine Slack channels to see what kinds of questions come up?
David - other tools, fedora migrate gem - may not be as profitable to spend time on this one. More focused on migrating into specific Hydra/Sufia environment at the time.
Mike - specifically designed for folks using Sufia which is no longer a thing. Would take substantial work to have it function with Hyrax and that hits only a portion of the Samvera community, probably dead code at this point and not a good option for us to consider at this point.
David - migrate 7x in Islandora - Islandora working on this and it will do content migration.
Erin - are there things we can learn from this for what we should set up for Fedora migrate?
David - can configure in Drupal.
Andrew - what is Drupal doing that makes it so easy.?
David - Danny has done a YouTube video and it looks pretty straightforward. Would like to see what is working well and have it help in building out Fedora migration tool.
Este - concern about what happens to metadata in the Islandora migration.
Erin - would be good to talk to other types of staff like metadata folks.
Scott - we give people the option to look at their xml while building tools to get the data migrated.
David - migrationutils highest value to work on at this point.
Andrew - migrationutils reads Fedora 3 via API or what is on disk, and writes into Fedora via the API. Increasingly thinking of going from file system to file system. From tools he agrees, but there might be a higher level recommendation to write from disk to disk rather than API, which could be a new tool.
API documentation
David - summarizes API. Utility of API is already well known. You can migrate through the API but it is slow. REST, one object at a time. Have heard that the API ingest into 4 is so slow it is not useful for mass migration. Could take 6 months to move data. NLM projected at least six months.
Scott - stumbling block. Interest in performance and scalability. Finding a bottleneck with the triplestore in Fedora 3. Not a Fedora problem necessarily.
Andrew - use half of the migration tool - reads from Fedora 3 and writes to Fedora 6 in OCFL.
David - the stuff is on disk. Suggestion that Fedora 6 could write to comply with objects on disk rather than other way around where objects conform to what is acceptable to the application. Could still use API, but could just write to disk in OCFL compliant format and that would be faster.
Erin - are we going to recommend people wait until FEdora 6?
David - depends on the amount of content.
Andrew - 6 is resolving issues in FEdora 4 and 5. Fedora 3 has flat hierarchy. Fedora 4 and 5 requires to change urls.. in Fedora 6 can keep urls and keep flat hierarchy, and have no modeshape.
Scott - would almost be two different migration utilities from 3 - 4/5 and 3-6.
Erin - grant focus is Fedora 3. Fedora 6 is well underway. Don't know the timeline yet. List of recommendations to publish with grant project - who to talk to about at what point server conversations with IT about last date of moving. Two rare instances where institutions who need to migrate or they have to turn it off.
Scott - this is a coming issue. Java 11 is coming at his institution, and Fedora 3 won't work on Java 11.
Mike - have had some conversations. No one says will stop supporting Java 8. Threat of something tanking and having a problem is getting greater.
Scott - no bug fix for end of life for Java 8. They use free SDK. Part of reason to migrate to 11 is to use the open JDK. Other issue with Fedora 3 - a lot of libraries and jars in it that are old and have bugs and security flaws that aren't being updated, and will get pushback from security admins.
Tim - in charge of everything from wall plate out - they aren't worried from pressure from IT at this point.
Erin - would like to send out an email to the whole advisory board about decommissioning Fedora for security/support perspectives, and who is applying the pressure.
David - this is a major problem. It could be a problem for us.
Erin - means the time pressure for 6 is even greater. This is interesting...
Tim - sees this in the espoused mission of DPN - to make sure that content wasn't lost. We are building a case taht the lost may not be the preservation strategy, but people aren't resourced to get their stuff out of an aging infrastructure. Not just the technology uplift from 3-6, but also shop it around as a crisis or threat to loss of content. The more we focus on that, the more evidence that it is a cross institution national issue, not just a technology issue.
Erin - this seems like a compelling argument to IMLS.
Scott - another key for Fedora 6 is the OCFL, which speaks to preservation.
Este - we will go to 6, but not 4 or 5, but we need to have it go well.
Erin - we need to support the first couple migrations to 6, with site visits to make sure it is good.
Scott - Bitcurator consortium - has a deal if you join for 6 months, you get three days of support. They walk you through a process - targeted at a very concrete level for institutions not well resources or technically in depth. Can put in contact with some folks from Bitcurator. Uses video calls, not on site.
Erin - a program institutions could apply for - very interesting idea beyond picking a few institutions to start with.
OCFL
David - helps with speed issues with migration and batch ingest.
Scott - solving not just a migration problem as Tim said, but a preservation problem.
Erin - expanding on the risks to the content in terms of the deprecated applications.Eri