AA203 Demystifying Laserfiche 8 Migrations Justin Pava, Software Release Manager

How to Ensure a Stress-Free Migration! Laserfiche Database Basics The Migration Utility: What’s New Performing a Database Migration Post-Migration Considerations Migration Best Practices

The Laserfiche Repository A Laserfiche Repository is composed of 3 components: Volume Files Stored in Windows File System Full-Text Search Indexing Files Database Files Stored in Database Management Server (DBMS) The .mdf and .ldf files for MSSQL/MSDE A user schema within the overall database in Oracle

Database Migration Process 1) Creates new database with Lf 8 schema 2) Transfers data from the original database to the newly created one 3) The original database is not modified in any way – Instant backup! Data transfer performed entirely through DBMS – Server not involved until afterwards

Laserfiche 8 Migration Utility Installed with Server 8 Installation Created on top of the 7 Migration Utility If you know 7 Migration, you know 80% of 8 Allows Migrations directly from 6 to 8 The volume and index files are not touched during this process Updated independently to limit downtime

Migration 8 – What’s New Field Merging Expansion DB Handling Fields now independent from Templates Automatically merge identical fields together Expansion DB Handling New Thumbnail (lft) and Word Locations (loc) data no longer written to database in 8 Migration WILL keep them there Migration from Oracle

Migration Utility 8 Enhancements Migrates Lf 7 Audit Data Converts to Lf 8 Binary format Object ID’s are retained Important for direct Web URLs Can resume in-progress Migrations Enhanced Progress Indicators

Performing the Migration: Initial Setup And Options

What to know before starting Source Server must be off or read-only Do NOT try to perform migration while data could be changing! Server 8 cannot be installed on same machine concurrently with Server 7 Can perform migration between two machines DBMS does not need to be the same

Migration Options Source DBMS and database Target DBMS and database NOT Laserfiche Server and Repository Target DBMS and database Still not Laserfiche Server and Repository ‘Advanced’ Options Thumbnails Auditing Field Merging Pre-Migration Check

Performing the Migration: Logging and Constraints

Database Constraints Constraints protect against corruption Written into the actual table definitions Examples (from 7 migration): FK_DOC_TOC: A Page entry in the DOC table must reference a valid TOC ID (Tier 1) UNQ_TOC: Two documents in the same folder cannot posses the same name (Tier 2) CK_Pos: A template field reference in TFields cannot have a negative position value (Tier 3)

Database Constraints: Migration Ramifications Laserfiche 6 contained very few database constraints, 7 added many, 8 added more Traditionally items that don’t actually display issues (not visible through Client) but will cause an error during migration if unchecked The Migration Utility should handle all the possible constraints – either by fixing or not including them Tier 1 – Generally are left out of the migration Tier 2 – Migration Utility will fix encountered items Tier 3 – Logged in Pre-Constraint Check, then generally left out

Migration Logging Logging is automatic Cannot choose not to generate log Name based on repository and mig time Placed in Server installation directory Unexpected Migration Errors display in migration UI and log – ‘Expected’ Migration Errors (DB constraints) only display in log Unexpected Errors will halt migration so can be re-run from same section

Constraint Logging Handled constraints are included in the log files Not generally displayed in UI Migration Help File (migration.chm) contains information about all handled Constraints

Pre-Migration Constraint Check Tier 3 Constraint violations generally mean invalid data (like in Tier 1) but MIGHT be salvageable The Pre-Migration Constraint Check scans the source database for data that would trigger Tier 3 Constraints Requires high familiarity with database structure

Performing the Migration: Repositories, Volumes and Index Files

Repository Registration Makes the Server aware of the migrated repository First point where 8 Server is used Registration can be completed as part of Migration process, or afterwards through standard Registration Wizard Information provided is the same ‘Cancel’ Migration at Registration step to register later – will not require re-migration

Interaction with Volumes The Path Preview dialog updates based on the provided Registration Path Displays expected location for all volumes, based on provided Repository Path Does not modify any paths itself!

Full-Text Search Index Files Laserfiche 8 uses new Search Engine 7 Index files are NOT compatible with 8 Following Registration, Migration will clear out old index files and trigger re-index using new format Only re-indexes previously indexed documents Long process, so repository is made available for use during it

Migration Considerations and Best Practice Recommendations

Non-Migrated Information Thumbnail Data: Very large data block that is regenerated as needed Audit 6 Information or Archived Audit 7 information All Workflow 6 or 7 information Includes WorkTOC: A copy of the entire TOC table Can result in significantly smaller database

Special Notes Recycle Bin Entry (ID = 2) Everyone Group Now a Windows Account Expansion Databases (Team Systems) If migrating to MSDE, MSSQL:Personal Edition or MSSQL: Express Security Mapping (Examples next page) 6/7 security mapped to 8 equivalents Full mapping tables in DevNotes and Migration Guide

Security Mapping Examples Some examples (not comprehensive): Delete Entry Access (6/7)  Both Delete and Delete Pages Entry Access (8) Manage Metadata (7)  Create Template/Field, Manage Template/Field, Manage Tags, Manage Relationships, Manage Public Stamps (8) Template ‘Read’ Access Right in 8 based on Field Access Rights in 7 Unchanged: Allow/Deny, Inheritance, Group Membership, Trusted/Denied Windows Accounts Migrated entries have no owners New security concept in 8, see ‘designing security’ for more information

‘Migration’ via Volumes An ‘alternative’ to the Migration Utility is to just create a new repository and attach volumes exported from the original This is generally only useful for very small repositories without security or RM setups or when upgrading from Laserfiche 4 or 5 Reasons For Reasons Against Retains most basic information: Documents, Folder Structure, Templates, Annotations Loses database information not included in volume export: Users, Security, Records Management Does not require that source Database be version 6 or 7 Can be very tedious for repositories with many volumes Volume attach is not as effective as dealing with Database Constraint Issues

Best Practices: Conversions/Upgrades Migration process will create fresh database on any DBMS Doesn’t matter where source was Database Migration is BEST time to: Move between MSSQL and Oracle Upgrade from Team to United Move DBMS to different machine Upgrade version of MSSQL or Oracle Servers Let the Utility handle the move for you!

Best Practices: Make Source Read-only Migration is performed in blocks Not all data is obtained at the same time Must ensure that data is not present at one point and removed or modified later Either take source off-line or make completely read-only ‘Transition Volume’ – Create a fresh volume for ‘new’ entries and do volume export/attach of that one later Still not recommended, but if you MUST allow new entry creation…

Best Practices: Set up your New Repository Recycle Bin Disabled by default on migrated repositories Outlook E-Mail Import Settings Now configurable repository-wide Windows Accounts New best practice for LF 8 security setup System Managers Determine who can create/manage repositories ‘Bypass Browse’ and ‘Bypass Folder Filter’ Security privileges with performance implications

Best Practice: #1 item to remember Update your Backup Procedure! New DBMS, New Database, New Repository Location 6 months from now, you don’t want to find out you’ve been backing up the old repository the whole time!