Migrating from Lockpoint Server/Data Center - Lockpoint Cloud

Table of Contents


General Migration Procedure

Migrating from Lockpoint Server or Data Center to Lockpoint Cloud is performed manually. However, the general configuration complexity of Lockpoint is low, so migrations generally require little time.

Recommendation to Ask Users to Unlock Attachments Before Migration

Our best-practice guidance is to migrate global and space-level configuration of Lockpoint, but not to migrate individual attachment locks.

Before performing a migration, we recommend that end users be instructed to save their documents and release all of their attachment locks.

Attachments are typically locked when the attachment is a "work-in-progress" with edits being performed. Even in the absence of Lockpoint, we strongly recommend avoiding having any attachments as work-in-progress during a Cloud migration. For example, page URLs will differ between the Server and Cloud sites, and different editing mechanisms are available on Server. Additionally, the Atlassian Companion is not available on Cloud, so any in-progress edits with the Companion cannot be automatically uploaded after a Cloud migration. All of this means that users with in-flight edits are likely to experience difficulty finding the correct place to upload their documents, which may lead to confusion and possibly lost work.

For these reasons, which are largely unrelated to Lockpoint, we strongly recommend to customers that they ask their end users to end all edit sessions and unlock all attachments prior to a Cloud migration, and if needed, to re-lock and restart the editing process once the migration is complete.

Note: once the migration is performed, all attachments will automatically appear on the Cloud site as unlocked, regardless of their lock status on the server. 

What happens if users do not unlock all their attachments before a migration?

We recommend that you ask your users to unlock attachments, but only to emphasize that users should not have any "in-flight" edits in place during a migration. While no technical problems are created by in-flight edits, as written above, these types of edits can easily lead to user confusion and difficulties finding the correct location to re-upload the modified attachment, so we we suggest discouraging them.

Regardless of whether an attachment is locked or not on Server/DC, all attachments will be correctly migrated to Cloud, and all attachments will appear as "unlocked" after the migration. If a user wishes to have a particular attachment locked on Cloud after the migration, it is left up to the user to go and re-lock the attachment.

Consequently, we recommend asking users to save their changes and unlock their attachments before the migration. However, there are no technical consequences to migrating attachments that are locked on the server side.



For a successful migration, we suggest performing the following steps:

Step 1: Perform End User Notifications

As recommended above, we suggest asking end users to release all of their attachment locks, to finish any attachment editing sessions, and to upload all modified attachments before the Cloud migration. Remind users that their attachments will become automatically unlocked when the migration is complete.

Step 2: Copy Global Configuration

There are 4 simple on/off settings in the Lockpoint global configuration, whose settings should be copied manually to the Cloud site.

The recommended steps are:

  • Step 2.1: On Lockpoint Server/DC, navigate to Admin Toolgear → General Configuration → Cenote Lockpoint
  • Step 2.2: Record the values of "Activation defaults" (Enabled/Disabled)
  • Step 2.3: Click the "Unlock Timeouts" tab
  • Step 2.4: Record the values of the checkboxes (enabled/disabled) and hours fields (number) for email warnings and unlocks.
  • Step 2.5: Navigate to your Confluence Cloud site, select the admin toolgear, and select "Cenote Lockpoint"
  • Step 2.6: Reapply the above settings on the "General Configuration" and "Unlock Timeouts" tabs.

Note: Lockpoint Cloud does not support the customization of email templates.

Step 3: Copy Space-Specific Configuration

The vast majority of customers do not have space-specific configurations that override the global defaults. In the case where these customizations exist, they are generally few in number and we suggest that these settings also be copied over manually.

To see which space-specific customizations have been applied on Lockpoint Server/DC, run the following SQL query:

-- For MySQL, omit the quotes (") in the query below

SELECT S.spacekey, LA."TYPE", LA."LONG_VALUE",
  LA."BOOL_VALUE" from "AO_4ED842_LPATTR" LA
LEFT JOIN spaces S on S.spaceid=LA."SPACE_ID"
WHERE S.spacekey IS NOT NULL
ORDER BY S.spacekey;


The result will be similar to the following:

 spacekey |      TYPE          | LONG_VALUE | BOOL_VALUE
----------+--------------------+------------+------------
 ATTACH   | WARNING_TIMEOUT    |         10 |
 ATTACH   | UNLOCK_TIMEOUT     |         20 |
 ATTACH   | LOCKPOINT_ENABLED  |            | f
(3 rows)

This example shows that one space has overrides, where the space key "ATTACH" has manually overridden defaults of:

  • Warning timeout = 10 hours (a value of "0" means this feature is disabled)
  • Unlock timeout = 20 hours (a value of "0" means this feature is disabled)
  • Lockpoint enabled in space = No ("t" or "1" means Yes, and "f" or "0" means No)

To apply these settings, navigate to each corresponding space on your Confluence Cloud site, select "Cenote Lockpoint Admin" on the left sidebar, and then reapply these settings on the "Permissions" and "Unlock Timeouts" tabs. The absence of a setting listed for a particular space means that it is using the global default.

Step 4: Need Further Help?

The above steps are sufficient to complete a migration of Cenote Lockpoint from Server/Data Center to Cloud.

Do you need additional help, or does the above process appear to be time-consuming in your environment? Please contact Cenote Support to see if we can help you further with your migration.