Staff are not using the frontend at all, but are connecting to the MSSQL database via Access.
They are not writing to the database, only reading from it as a point of reference for legacy data workflows. Data that was appropriate for ASpace from MASC was migrated successfully as part of the ASpace migration, but some legacy data remains in MASC that is needed only for reference by SC staff.
SC staff are open to using a different method of access for the data, such as referencing static files somewhere, so long as they can still search the data. Kate is working on converting the MSSQL data into CSV for flat file import into Azure Data Studio as a possible method. The SQL dump file is having problems, so they will request access to the database itself via the client in an lsupport ticket.
Another possible approach: export the database as a local Access database for staff to use. If we take this approach, we should not put the database file on the shared filesystem as in the past, this has led to corrupted Access databases. Instead we can try staging the static file(s) somewhere that requires users to download them in order to work with them (example: Google Drive).
(Esmé) PUDL sunsetting
Cliff and Francis working on setting up the redirects.
Reingesting two Mudd collections (Historical Buildings and Historical Postcards); ingested as two large MVWs with individual children per photo initially, which never worked well. Instead now building individual items per photograph, building a DPUL site, and eventually changing references so that these items in PUDL show up in PULFAlight.
The archiving process that Operations does for sunsetting systems should cover whether or not shutting it down will cause a disruption.
PUDL is a VM.
(Steph) Lib-ruby-prod, bib-data-alma-worker3, and bib-data1 and 2 have been decommissioned
These are now decommissioned. Some was pre-Alma work.