Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Download the SigningHub patch file from the link that is provided by Ascertia Support and copy it on the SigningHub server.
  2. Extract the patch in a new folder.
  3. Take the backup of SigningHub existing installation directory.
  4. Copy the patch files and paste them on the SigningHub installation directory. When asked choose overwriting to overwrite the existing files.
  5. Restart the "World Wide Web Publishing Service/Internet Information Services" to impact changes.


How to Migrate Data Between an upgraded and clean installation of SigningHub?

SigningHub makes use of a Data Encryption Key (DEK) which is used to encrypt all documents and personal information.  When the Key Encryption Key (KEK) is turned on in the SigningHub Admin the DEK gets encrypted by the KEK assigned to the Client ID in ADSS Server > Client Manager > ClientID > Advanced Settings.

When decrypting data, the KEK will decrypt the DEK and the DEK will be used to decrypt the documents and personal information.  When the KEK is switched off in SigningHub Admin and the KEK is available in ADSS Server, SigningHub will decrypt the DEK and then re-encrypt the DEK with a SigningHub KEK.  This means that the DEK doesn’t change and it also means that you should be able to switch off the KEK in SigningHub admin, move and reconfigure SigningHub to the new ADSS Server and switch on KEK using the KEK generated on the new ADSS Server, therefore allowing you to remove the migrated ADSS Server.

Steps completed for the testing in a local environment:

  • Created a replica environment starting with SigningHub 6.5 with KEK (software) enabled
    • Uploaded 10 documents, 5 of which were signed with 3 in progress and 3 in draft/pending states
  • Upgraded using the wizard to 7.6 (KEK enabled)
    • Uploaded an additional 10 documents, 5 of which were signed with 3 in progress and 3 in draft/pending state
  • Disabled the KEK in SigningHub Admin
    • Stopped ADSS Server services and restarted SH IIS to ensure cached KEK is flushed from memory
    • Tested access to documents that were uploaded in both SH 6.5 and in SH 7.6
    • Restarted ADSS Server services keeping KEK disabled
    • Uploaded an additional 10 documents, 5 of which were signed with 3 in progress and 3 in draft/pending states
    • Signed previous documents that were uploaded in the points above
  • Migrated SigningHub 7.6 instance to use new ADSS Server Instance
    • Enabled KEK in SigningHub Admin against the new ADSS Server instance
    • Tested access to documents both new and old
    • Created new workflows with documents that were signed and unsigned
    • Tested access to both new and pre/post migration old documents
  • Switched off KEK in SigningHub Admin again
    • Stopped ADSS Server services
    • Restarted SigningHub instance IIS
    • Ensured all documents that have been uploaded in all stages above are accessible

In the light of these testing results, this worked as expected without any issues, we were able to access all documents as the DEK stayed intact.

Please ensure to take all the necessary backups and thoroughly test the change at your testing environment prior proceeding with your Production environment. Additionally, it is highly advisable to follow the necessary caution when completing this change.