Using Configuration Migration Utility to Create a New Test Environment?

[Stephen_Dignam]

We would like to use the Configuration Migration Utility to recreate our Production OnBase environment in a Test OnBase Environment.

I had some questions regarding the process though.

1. We currently have a Test OnBase Environment (created on 03/03/2015, the last time the Configuration Migration Utility was used). This was prior to my position as System Administrator for OnBase at my institution. Can we reuse this same location for the new Test Environment? If yes, what steps must be taking prior to running the tool?

2. Will this tool create a clone of all users and processes (COLD, DIP, Workflow, etc.) currently housed in our Production Environment?

3. Will the tool create an empty shell, meaning no documents, when the new Test Environment is built? (An empty shell would be preferable for our purposes.)

4. What steps are needed to break the link to Production after running the tool?

5. Approximately how long should we expect this process to take?

Apologies for the number of questions, but this will be my first experience with this process and I want to make sure I have all my ducks in a row.

Thank you.

[Brian_Smith · Accepted solution]

Hi Stephen,

1. In order to create a new test environment, you'll want to delete the existing test database and create a new blank database. If you use the same name, you won't need to recreate any existing ODBCs.

2. Yes, this tool will create a copy of your existing users/document types/processes.

3. The new test database will be a shell with no documents. You will have an option during the migration to bring over system documents however. This can be useful for things like bitmaps and icons.

4. The only step necessary to break the link is to select the "Stand Alone Test System" option when you run the process. If you forget to select this option, and need to break the link post-migration, please contact your first line of support for assistance.

5. This really all depends on the size of your database. The more users, document types, import processes, etc, the longer it will take to create the shell.

Hope this helps!

[Stephen_Dignam]

Thanks for the quick response Brian! That is definitely helpful information!