How do I request that a test database be refreshed with the latest copy of production?

Frequently, a client asks to refresh their test environment with real production data to test a new feature or process. The client may also want to restore the test over production during go-live, where data may be loaded in the test environment for verification and copied to production prior to go-live.

Database refreshes are requested by Veson IMOS Platform clients. On-Premise clients will need to refresh their test database by themselves.

To request the database refresh, clients will need to create the request through the Help Center via the Product Support option. Please expect each database refresh to be completed within a two-hour window, but in most cases, the task can be completed within one hour. During this time, users should log out of the target (test) environment that is being refreshed. The source (production) environment is not affected by the restoration process.

Please note that the database refresh is not official unless otherwise confirmed. The confirmation of the scheduled window depends on the availability of our resources. In the event that a request coincides with a public holiday within the specified time zone, we will reach out via the ticket to reschedule for an alternative window time.

Details to be provided when raising a Standard Database refresh request:

When raising a standard database refresh request via the Help Center, please ensure that the following details must be provided:

1. What is the source environment/database name?

   1. This is usually the Production environment data (E.g., ABCD_prod) from which the data is extracted.
      

2. What is the target environment/database name?

   1. This is usually the Test environment data (E.g. ABCD_test) where the extracted data above will be copied into.
      

3. What is the date and time in UTC time zone for this to be carried out? Please propose two window times with 2-hour intervals each between 01:30 and 20:30 UTC on Mondays to Fridays.

   1. The date and time MUST be specified in UTC time zone and the two window times needs to have a 2-hour interval each between 01:30 and 20:30 UTC on Monday to Friday.

   2. The earliest time window must be 2 business days in advance of the expected execution time of the database refresh. See the following example.

      1. Example: If you raise a ticket on 7 October 2024 (Monday) 02:00 UTC requesting a database refresh for the test environment, the earliest window time to propose is 9 October 2024 (Wednesday) 02:00 to 04:00 UTC. The second window time can be any later date and time within the "Standard ISD request window“ table below (e.g., 9 October 2024, 04:00 to 06:00 UTC).

   3. Please note that changes CANNOT be accommodated at weekends.

      1. Example: If the proposed window time is 12 October 2024 (Saturday), 01:00 - 03:00 UTC, this request cannot be accommodated.

   4. For a point-in-time refresh of the test database, please refer to the following section.
      

4. Do you want to preserve user info (security list) on the target environment?

   1. The answer should be a “yes” or “no”.

   2. The default is no. This means that the security list from the target (test) environment will be replaced by the security list from the source (production) environment.

   3. If the answer is yes, please note that both the source and target environments must have the same schema version. If they are different, we will contact you to arrange for a schema upgrade of both the source and target environments to the latest version.
      

Standard ISD request window (Mon-Fri, excluding regional public holidays):

Note: Any request outside the above times needs to be checked internally for approval.

For Point-in-Time Database Refresh

For a simple standard copy of the database (i.e., the latest production copied to test), two business days' notice is required. If a test database needs to be refreshed with a copy of the production data from a specific point in time in the past, the date of the point-in-time database cannot be more than 10 days old from the required point-in-time execution date. In addition, two weeks' notice is required. We recommend submitting the request as early as possible.

Example 1:

If the test environment needs to be refreshed with production data up until 30 September 2024 at 12:00 UTC, the LATEST time to execute this request is 10 October 2024 at 12:00 UTC. With the two-week notice, the latest time to submit the request will be 26 September at 12:00 UTC.

Example 2:

If the test environment needs to be refreshed with production data up until 30 September 2024 at 12:00 UTC, and a request is submitted on 23 September 2024 at 12:00 UTC, the earliest execution time, considering the two weeks' notice, will be 7 October 2024 12:00 UTC.

Things to note before the database refresh

Before restoring a database refresh request, please bear in mind:

• The configuration flag list will NOT be overwritten.

• Messaging service configuration will NOT be overwritten.

• Customers have the choice of whether the users are retained from the restore or overwritten (in question 4 above).

  • If you have a user who is used for API calls, take note of that user's email address. Once the database is restored, change the email address back to the original one (i.e., before the DB restore) in the user profile of the Security list. Log out and log in again to see the Veslink API section.

    

• When the Test environment is on a later schema version than the Production environment, the Test schema will be rolled back to match the Production schema after the refresh.