In my many years as a solution engineer, I have had the opportunity to migrate tons of solutions up to the Hyland GCS Cloud. Working with the GCS team and the customer to coordinate each step of the process. The ultimate goal in any migration is to minimize downtime and provide a seamless change to the end-user.
When a solution is premise-based we tend to take a lot for granted in the area of system interoperability. Whether it be the posting of an autofill file to a share or managing DIP the system is completely accessible for the OnBase admin. Typically, that server has access to all of the necessary resources it may need. Due to the secure nature of the GCS environment, some of that access now becomes limited. Below is a list of items to consider as you begin the process. Hopefully, this will help you to mitigate as much risk as possible.
Define Your Processes
Sometimes capture processes such as DIP, COLD, or Autofill’s are managed by different departments or admins. You will need to compile a complete list so you can identify what changes will occur when the system is hosted in the Cloud.
- Local forms and other files accessed by the app server – Does your premise solution access external data for drop-down lists or Autofills, or do you leverage user forms in workflow. All of these extraneous resources will need to migrate to the Cloud, so system adjustments may be required.
- Are your disk groups complete or are you missing volumes or files? – It is possible, especially on older systems, that may have once had a WORM storage solution or other Disk Group media that is no longer in use. If so did all the files get placed back into the current Disk Group before that system was retired?
- Client authentication method – In many premise solutions, the Active Directory (AD) is used for client authentication. As you move to the cloud, other methods may now have to be factored in, such as ADFS or other SSO providers. Naturally, there is the Native OnBase authentication that will remain intact.
The “Freeze” and Managing Downtime
Typically there will be a “final” upload of the active database and new Disk Group data to the cloud environment. This will entail some downtime as the database gets restored and all of the services, schedules, and processes get reset. During this time you can still do retrievals from the premise system but all day forward processing is stopped until the cloud system is active. Managing this will be important to maintain business continuity.
Communicate, Communicate, Communicate
This is the most important thing you can do in this process to ensure it is a smooth transition. A detailed project plan and good project management are critical for cloud migration as there as many factors to manage.
Testing in the New Environment
Prior to the actual “Go Live” it will be critical for all stakeholders to do thorough testing of their current process as it will now be done in the cloud environment. In some instances the change will be unnoticed, but for processes that may be “Thick Client” driven it may be a completely different interface. Documenting these changes and properly communicating them to the end-users will be a critical step.
Go Live Migration
As much as you have planned, communicated, and tested, the possibility of one or more items being overlooked is always a possibility. Be prepared for the unexpected.