Pure hosting migration project outlinePure hosting migration project outline

Introduction

If you wish to move from self-hosting your Pure instance to us managing your hosting in the cloud, first it needs to be clarified what hosting package you would like to have and when it should be available, which is done in collaboration with Elsevier's Sales and Solution Engineering team. You can find technical documentation about cloud hosting here: Pure Cloud Hosting - AWS. The recommended setup is standard hosting, and you can include a staging server if you want to regularly test the new releases and/or various configuration or integration changes.

Make sure to assess how much storage you need in your new cloud server. One TB storage is included and extra space can be purchased as needed.

Your Solution Engineer or Customer Success Manager will work through creating an agreement with you, to cover hosting in AWS. Once this is done you will be assigned an Implementation Manager (IM), who will guide you through the process of migrating to the cloud. The migration to cloud can usually be completed within a timeframe of 2-3 months. The process is outlined briefly below - during the project your IM will provide you with more detailed information and also a customized project plan.

1. Kickoff meeting and preparation

Your IM will organise a kickoff meeting to talk through the process of migration with you. They will outline the steps involved in the process, ask you questions about your self-hosted server, and work with you to assess areas of particular focus for your migration. The resulting project scope document will be used to plan out the rest of the migration project. You will also be granted access to a project tracking tool that you will use to communicate with your IM.

2. Creation of cloud Pure

To migrate your data from your self-hosted server to the cloud, an application will be provided for you that dumps your Pure database and files into an Amazon S3 bucket created specifically for your migration, as well as your Pure's configurations and audit archive files. Your IM will generate a copy of this migration tool specific to your new environment. It will come packaged in a zip file with instructions on how to execute it. The migration tool needs to be pointed at your database and should be executed on your Pure server, so that it has access to any local files. You do not need to stop your Pure to run the tool at this stage.

When the run is finished, your new cloud Pure will be created. Your IM will then perform some initial checks and configurations before granting you access.

3. Configuration and testing of cloud Pure

Once you have access to your new cloud Pure, you can begin testing. Many Pure integrations will work exactly the same whether the instance is self-hosted or in the cloud, since they use publicly available APIs. For your own services, there may be issues where services are behind firewalls and IP restrictions. Below are the areas you will need to review in order to identify any necessary adjustments to configurations in Pure, or connections with Pure.

3.1. Data synchronization jobs

Synchronization jobs, such as those for Person or Award data, may need changing to ensure Pure can continue to access the source data configured in the jobs. If you are using XML, this may mean granting your new cloud Pure access to the location where your XML files are stored (a list of the outgoing IP addresses of our servers can be found at IPs in use for Pure and Pure Portal). If you are using database sync, then you will need to grant your new cloud Pure access to your database server via an SSH tunnel. See SSH Tunnel from Pure server to Customer network for details of this process.

3.2. External authentication

If you are using an external authentication like SAML, this needs to be set up too. Here the configuration in the hosted environment should be very similar to the configuration of your local Pure, but you will need to update your external authentication system, as well as your network setup, in order to give access to the Elsevier-hosted Pure environment.

3.3. Online import sources

If you are using online import sources, like Scopus or Web of Science, you need to ensure that you will also have access to them from within your Elsevier-hosted Pure. The IP addresses for your system are listed at IPs in use for Pure and Pure Portal. With this information you should be able to contact the provider of the import source to extend your access to cover your hosted Pure system too. Most sources use credentials (username/password) to provide access, which should continue to work without any change required in the hosted environment. Note that if you have IP-based access to Scopus, this will need to be replaced with an institutional token in the Pure configuration.

3.4. Repository connector

If you have set up a repository connector, a connection needs to be established from the hosted environment to your repository. You should create a clone of your repository for testing purposes. The repository connector configuration that has been copied from your local environment should all still be valid, but of course you should connect it to your test repository first. We recommend doing a full backup of your repository just before your Pure gets transferred to the hosted environment (step 4).

3.5. Mail settings

For Elsevier-hosted environments, the default mail server setup is that email notifications from Pure are sent from purehosted@elsevier.com. Alternatively, you can use your local SMTP server to send Pure notifications. This allows you to use a different email address; most likely you will choose the address that you have used in your local Pure. In your locally hosted environment you likely already have defined a connection to your own SMTP server which you can continue to use, but please refer to your IT department to make sure the hosted environment is allowed to use a local SMTP account.

If you choose to use the Elsevier SMTP you still have the option to set the "Reply to e-mail address" to an email address in your own domain. Adding a customized "Mail signature" will also help to ensure the receiver recognizes that the mails are coming from your Pure.

During testing, ensure that the option forced recipient of mail is enabled (Administrator > System settings > Pure mail), along with exclude from force recipient. Mails from the Elsevier-hosted system will then only be sent to the specified addresses, so your users will not receive any mail from the Elsevier-hosted system while you are still setting it up. When you go live, disable this feature again, so that your users will get notifications. 

4. Preparation for migration

A few weeks before your planned move to your cloud Pure, your IM will meet with you to describe the process and confirm the timeline. In the week before, a few preparations should be completed to ensure the move goes smoothly - for instance, running the migration tool once more, this time in files-only mode, will mean it takes less time on the day of the move. Your new cloud server will have been created at a standard URL in the format youruniversityname.elsevierpure.com. If you want your new, Elsevier-hosted Pure instances to exist at different URLs, or the same URLs you presently use for your locally hosted instances, you will work through the processes described at Custom URLs for hosting migrations with your IM. If the URLs are already in use by your current instances, the switch will only happen on the day of the move. 

5. Move to cloud Pure

The final move to a cloud Pure is usually accomplished in 1 or 2 days, although your test migration(s) should give you a clearer sense of how long the final migration will take.

You will begin by stopping your self-hosted Pure and running the migration tool. Pure needs to be stopped both to ensure a clean copy and so that new data isn't entered into your local system that won't be included in the migration. When the export is complete, Elsevier will use it to populate your new Elsevier-hosted Pure instance, overwriting any changes you have made during the testing phase.

You will then test the new instance and make any configuration changes that are needed for SSO, synchronizations, etc. We recommend using the project management tool to develop a checklist for yourself as you work through the previous steps of the migration process. Once the system is confirmed as functional, custom URLs can be updated, and you can allow users back into your system.

6. Ongoing support

6.1. Non-production environments

Once your production has been moved to the cloud, any additional staging environments you may have requested will be created by cloning them from the production instance. Note that this will copy all configurations, so before jobs are enabled you may wish to change their settings within the system to point to the appropriate environment (for example synchronization jobs or SSO that use non-production data).

Should you ever need your staging environment refreshing with another copy from your production system, simply raise a support request and our team will schedule a suitable time to copy your data over.

6.2. Version updates

If you have purchased standard hosting, then new versions of Pure will be automatically applied to your server. You can see details of the schedule here: Release calendar. If you have purchased dedicated hosting then new versions can be applied by raising a support ticket, detailing which environment and Pure version you want updated.