You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Our successful Laserfiche server migration plan

posted on October 15, 2019

Our company recently migrated our Laserfiche 10.4 applications and databases from 2008 R2 servers to Windows Server 2016 servers. Knowing that downtime couldn't be avoided for some parts of the migration, I planned it to have the fewest possible activities scheduled for the our period of downtime (in other words, completing as many tasks in advance as possible).

Posting a general list of our migration steps in case anyone else is curious about what that looks like.

  1. Acquired all servers (application and database)
  2. Installed SQL Server on database servers
  3. Migrated over custom databases that we had created to support our processes (along with associated scheduled tasks, etc.)
  4. Activated IIS and Message Queuing Server features/roles on new application servers to support Forms and Workflow 
    1. https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-iis-2016-components-server.htm
    2. https://manuals.gfi.com/en/mailessentials/content/administrator/installation/system_requirements/msmq_2016.htm

  5. Installed Forms WITHOUT configuring

  6. Installed Workflow WITHOUT configuring

  7. Created folder paths that some workflows were dependent on

  8. Took repository metrics (size, filecount, etc.) for testing

  9. Created scheduled job (using 3rd party app) to regularly check for differences between the source drive containing our Laserfiche volumes and their destination on the new server. This allowed us to gradually copy over 3TB of data in the weeks leading up to migration.

  10. Sent out memo to users with info on what to expect and how to handle it. Mainly that our server name was changing, so they would need to update their existing repository connections and saved URLs, etc.

  11. Here is where the downtime starts.

  12. Stopped original Forms and Workflow services on source server

  13. Ran our file copy one last time to collect all the changes 

  14. Unregistered repository on source server

  15. Uninstalled Laserfiche on source server

  16. Migrated Laserfiche Audit Trail and repository databases from source to destination server (using SQL Server Backup and Restore method)

  17. Installed Laserfiche Server on new server

  18. Registered repository on new server, with connection to the migrated repository database

  19. Double-checked repository settings, including db connection and image drive location

  20. Migrated Forms and Workflow databases from source to destination server

  21. Configured Forms and Workflow with pointers to new Laserfiche and SQL Servers

  22. Updated connections in Forms and Workflows (like "Save to Repository" tasks, "Run Workflow" tasks in Forms. Repository connections and condition triggers, SDK scripts, "Retreive Business Process Variables" tasks and anything to do with external databases in Workflow)

  23. Overwrote custom databases with most recent data

  24. Downtime ended at this point

  25. Updated Quick Fields server connections

 

This is a bit simplified but represents the general process. Accounting for some troubleshooting along the way, we had just over 6 hours of downtime during the migration.

 

Other important resources used:

6 0
replied on December 19, 2019

Hi, thanks for the post. Approach is really helpful for large migration to reduce cut-off time.

 

Would you please mention what 3rd party app was used to check the differences?

0 0
replied on December 19, 2019

We used FreeFileSync. Their website is https://freefilesync.org/

1 0
replied on October 22, 2019

How you managed workflow/Forms running instance while you migrated from Old server to New Server?

 
0 0
replied on October 22, 2019 Show version history

We tested this on our dev/test servers first and found that the below series of steps would allow us to resume Forms/Workflow instances:

1. Stop all Laserfiche services on the source servers

2. Copy Workflow and Forms databases from source servers to target servers

3. When configuring Forms and Workflow on target servers, use the copied databases as the main dbs for each application. Doing this will prompt the system to ask if you really want to use an existing database, just choose "yes"

We had to shedule downtime for this, because we had to turn off all Laserfiche services first.

Doing the above allowed us to resume all activities and keep all old reports, and we didn't have to copy individual workflows or Forms processes.

Since our server names changed, links to Forms Tasks that had been previously been sent to users via email from the source system did not work. So we warned users of this and instructed them to use the Forms inbox instead of email links for a few days. Of course, server names also had to be changed in Workflow.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.