When your system is implemented on an external server and the implementation is ready to be moved in house, there are several steps that must be taken to transfer the KB and set it up on your own server. There are some kinds of configuration that are typically done or modified after that move has taken place. This article provides some steps that may need to be taken before and after the move.

Before the Move

If possible, install an  Agiloft standard demo KB early on so you have time to test installation and other applicable configurations, such as the Word API, LDAP, Email, and SSO. You can work on those items with Support while the implementation work is being done. When that setup is finished and tested, document all the final settings used so you can reapply them once you move the production KB over.

If any of these items apply to you, make sure to test them as part of your setup:

• If you are using LDAP sync, test that as part of the setup.
• Create any inbound email accounts you'll need and set up and test outbound email to both internal employees and external contacts.
• Create a separate endpoint for single sign-on for a production and test instance, if you plan to use those.
• If you use any scheduled imports, test their access to the SFTP site or other location.
• If you plan to use document comparison (redlining), test it by going to the Attachments table, selecting a new attachment and a previous one, and using the default redlining action button to see if it works.

Run the performance test in the Admin Console to ensure you have configured the server properly.

If you plan to use a custom login page, your implementer will provide you with a sample generic login page so you can see what you need to include. Set up the custom page on your server or website in advance.

If you are going to change the KB name, do that on the Agiloft server first so your implementer can correct any issues that come from that change. These issues can include modifying any scripts with global variables that include the KB name, any REST or SOAP API calls, login pages, SAML endpoints, and licenses.

Check the release on the Agiloft server against your own server. The release on the receiving server must be at least as recent or higher in number as the one on the Agiloft server to allow the import to work. If your release is earlier, you need to upgrade the server first.

Make sure you acquire your new permanent licenses before performing the move.

Performing the Move

When it's time to move the KB, follow the steps in Transferring Knowledgebases Across Servers to export the KB from the Agiloft server and import it on your own server.

After the Move

After the KB is imported on the new server, complete the steps below to make sure your KB is functional in its new location.

Outbound Email

You typically need to set up outbound email to run through your own email server. You might also want to change the default outbound address. For more information, see Outbound Email Settings. Make sure to test the updated configuration and make sure it works.

Inbound Email

Any inbound accounts that were using test email accounts need to be reconfigured with your own inbound accounts. You should have prepared these accounts before the move. Once the system is moved, the existing inbound accounts can simply be updated with new credentials.

LDAP and Single Sign-on

If you previously tested LDAP and single sign-on as recommended above, at this point you should copy the configuration that you already documented into the new KB. For more information, see LDAP Access and Single Sign-on.

Word API

If you were using the remote Word API from a hosted server, you need to do some reconfiguration after the move. You need to update:

• Any print templates defined as printing to PDF that used the Word API option instead of the Agiloft built-in conversion
• Any print actions that generate a PDF file using the Word API
• Any document comparison actions

Each of these items have an option to select the installed Word API or a remote hosted API. The option must be set to the installed Word API to continue working.

Install New Licenses

Install the new permanent licenses you received as part of your move preparation.

Update Global Variables

In most cases, you need to modify the Hotlink Server Root URL variable to point to your new host URL. You might need to adjust other global variables as well depending on what you've configured. For example, you should also check the Exit URL and Login URL variables to make sure they are set correctly, based on the location and configuration of any custom login or password reset page.

There are also global variables in the admin console that you might want to modify, such as the frequency for running rules. Be sure to store the admin console password in a safe place. To allow assistance from Agiloft, you might want to create a second admin console user for your implementer to use.

E-Signature

If you use DocuSign, you need to disable it on the hosted system. Then, disconnect and reconnect to DocuSign in  Agiloft on your server.

If you use Adobe Sign, deactivate the test account and set up your production account on the new server.

Scheduled Import and Custom Scripts

If you use custom scripts, upload the script to the correct folder on the new server. Also make sure variables used in the scripts are referring to the new KB.

Make sure all the rules and actions for scheduled import and custom scripts are pointing at the correct locations of the new KB.

Test Data

If you haven't deleted the test data, do so now. You can do this from the admin console by going to the KnowledgeBases table, clicking Edit next to your KB, then clicking the Delete Demo Data button. 

Set Backup Schedule

You need to set up the backup schedule and location for the new KB. Click Backup in the left pane of the admin console to adjust these settings.