How Can We Help?
What to be aware of when doing a data copyWhat to be aware of when doing a data copy
What
It is possible to copy data from one Pure environment to another. Most often this is done from a Production (A) environment to a Staging or Development (B) environment.
When copying data everything will be overwritten on the target environment (B), where the copy is added to, which essentially makes it equal to your Production Pure. This means you need to adjust your configurations and setup after the data copy.
Important
Since all data in the target environment (B) will be overwritten, you must ensure that you can access environment (B) after the copy has taken place as the current users in target environment (B) will be replaced with users from Production environment (A) and the authentication configuration will reflect that of Production.
We recommend that you prior to the data copy create a Pure Administrator user login in your Production (A) environment (it should not use SSO, create a user with normal Pure login instead). This user will be copied over to your Staging/Development environment (B), allowing you to log in after the data copy is completed. You can delete this user from your Production (A) environment afterward. Now you have access to your target environment (B) and can go adjust the configurations (see table below) and provide access to other users if needed.
Access problems: If you forgot to follow these recommendations and no user can access your target environment (B) in any way after the data refresh, then consider to do a new data copy, but this time follow the above guide.
How
This table provides examples of what you should verify.
Most importantly, ensure that access restrictions are enabled on your staging portal after a data copy to avoid it being public available (see below: Administrator > Pure portal > Portal > Users & security).
| What setting | What you need to check |
|---|---|
| Administrator > Integration > Export to ORCID | Make sure Sandbox mode is turned ON, if this is your Staging/Development. Only Production should be using the Production version of ORCID. Otherwise you risk overwriting ORCID data with data from Test. |
| Administrator > Integration > PlumX, WoS, Scopus and SciVal metrics | This is where you setup the metrics jobs. Check the job setup and configurations. It is a good idea to disable import of metrics on your Staging/Development, unless you are currently testing these. |
| Administrator > Datasets > Data Monitor Integration | Check up on your settings and credentials. |
| Administrator > Jobs > Cron Jobs | Your jobs will be stopped after a data copy has been applied. Make sure all the jobs you wish to run on this environment are set up correctly with the right scheduling, configurations and credentials, before restarting them. Below are some examples. The Scopus Citations Synchronisation Job: Check if the following are correct Institution token, Authentication URL (vendor only settings: API Key and API URL) QABO Import & Clean Up Job: Check the workspace configuration (Workspace name, Workspace ID, Service URL) Make sure to check other jobs like: Configurable User Synchronisation Configurable Organisation Synchronisation Configurable Person Synchronisation Configurable Supervisor Synchronisation Award Synchronisation Project Synchronisation (new) Consider if you want your Staging/Development server to import these data from your Production source system or are you testing changes in the data providers, and need to point to another system? |
| Administrator > Unified Project Model | Check if your settings are correct. |
| Administrator > System Settings | Pure mail: check settings (i.e. force recipient set to prevent double emails to users - this would usually only be applicable if you're copying production to test) Mount points: Make sure the correct URLs are used here. |
| Administrator > Security > Admin | Check the authentication method settings - it will reflect the SSO settings of Production after a copy. |
| Administrator > Security > Ws | Check whether Basic authentication is setup and if it should be. Check the filters added under Authentication requirements and content filtering. |
| Administrator > Security > Api keys | Check and correct that the Api keys listed are only the ones used for your Staging/Development. If you have a Pure Portal then the one called Description: DDP is used by the Portal and should not be deleted. If your Portal is not updating, then the DDP Api key may have been overwritten, if so please reach out to Pure Support. |
| Master data > Users | The Users will also bee copied meaning also the roles, report configurations and report templates. If you had some Users on your Staging/Development, which were not on Production, then they will be gone now. If you wish to keep some Users and their configuration, then make sure they/it is added on your Production before the data copy. |
Self-hosted
If you are self-hosted it might also be a good idea to check up on:
| What setting | What you need to check |
|---|---|
| Administrator > System information > Audit | Have you copied also the history and comments, when doing the data copy. |
| Administrator > Storage > File storage | You should configure storage to no longer use Production file paths and services. If you are on a hosted server this has been automatically updated as part of the copying of data. |
When doing the data copy yourselves, then it might be a good idea to look at setting up Tomcat command-line parameters. You can read more about that here.
Pure portal
If you have a Pure portal, then you should check the following:
| What setting | What you need to check |
|---|---|
| Administrator > Pure portal > Portal > Status | Check that you have the update table and that your Portal looks to be updating. If not please check your Deployment URLs (as mentioned in the row below), if they are correct, then please reach out to Pure Support. |
| Administrator > Pure portal > Portal > Configurations > Deployment URLs | Check if your Deployment URLs are correct. The two Portal public URL and the Portal API URL should be identical except the Portal API URL should end with /api/1.0/ |
| Administrator > Pure Portal > Configurations > Google Analytics | If you are using Google analytics you'll get some weird data if you have the same Google Analytics ID in several environments. We suggest you remove the Google Analytics ID on your Staging/Development. |
| Administrator > Pure Portal > Configurations > Cookie consent | The OneTrust ID will also be copied. The Production OneTrust ID will not work on your Staging/Development, which means the Cookie Consent Banner will keep being shown even though you have accepted. Please reach out to Pure Support to get someone to either remove the Production OneTrust ID or to replace it. |
| Administrator > Pure portal > Portal > Users & security |
To keep your User & Security settings on the Staging portal "Active" after the copy, we have added a function to disable pushing changes to the portal until you are ready.
This will make sure that the copy has the same setting toggled off and will stop the portal from publishing changes including overwriting the active security settings in your staging system |
Published at March 18, 2025