AWS Migration FAQ

Each customer environment will be migrated separately during a confirmed migration window. Verodat will contact each customer in advance with the exact date and time, any actions required and the expected period of service interruption.

The migration is part of a planned modernisation of Verodat’s underlying platform infrastructure.
The new AWS-based architecture is designed to provide:
​

The migration is about improving Verodat’s overall architecture and operating model. It does not imply that Azure itself is insecure or unsuitable.
​

No. This is a planned infrastructure modernisation and is not being undertaken in response to a security incident.
The move allows Verodat to strengthen and standardise areas such as platform monitoring, network isolation, access management, backup and recovery, and operational oversight. The investment is part of our ongoing commitment to proactively strengthen our security posture and the resilience of our platform.
​

Customer environments will be migrated individually between 21 September and 2 October 2026.
Verodat will provide a customer-specific migration notice containing:
​

Not all customer environments will be unavailable throughout the full 21 September to 2 October period.
​

Verodat will work with customers, where possible, to avoid known operationally sensitive dates, including month-end processing, regulatory reporting deadlines and other high-volume processing periods.
Customers should notify Verodat as early as possible of any dates during the migration period that would cause significant operational disruption.
​

There will be a planned period during which the affected customer environment will be unavailable or processing will be paused.
The exact duration will be confirmed in the customer-specific migration notice. During this period, users should not:
​

Verodat will notify the customer when the migration begins and again when the migrated environment has passed validation and is available for use.
​

Verodat will introduce a short processing freeze before the migration begins.
Where possible, processing already in progress will be allowed to complete before the cutover. Any upload that cannot complete before the migration will be reviewed and, where necessary, safely restarted or reprocessed by Verodat after the migration.
Customers will not normally need to resubmit a file unless specifically advised by Verodat.
​

Existing schedules and automation configuration will be migrated to the new platform.
Scheduled processing will be paused during the migration window and restarted after the environment has passed validation. Verodat will review any schedules that were due to run during the maintenance period and will either run them after migration or agree the appropriate action with the customer.
Customers should not create or amend schedules during the migration window.
​

The Verodat platform URL will change from:
​https://verodat.io
to:
​https://verodat.ai
Customers should update:
​

Customers should not rely on the old URL or existing deep links continuing to work after their migration date.
​

No. Existing Verodat usernames and passwords will remain unchanged.
Users may be signed out as part of the migration and will need to sign in again through the new URL.
Existing MFA settings are expected to remain unchanged.
​

Existing supported sign-in methods are expected to remain available.
Verodat will test standard username and password authentication, MFA and supported social sign-in options as part of the migration validation process.
Where a customer uses a dedicated SSO configuration, Verodat will confirm separately whether any customer-side change is required.
​

For most customers, no change is expected.
However, the change in platform domain may affect SSO configurations that explicitly reference:
​

Verodat will identify customers using dedicated SSO and confirm any required changes before migration.
​

Customers should allow access to:
​https://verodat.ai
over HTTPS port 443 before their confirmed migration date.
This may require updates to:
​

Where Verodat connects directly to customer-managed infrastructure, additional allowlist changes may also be required.
​

Yes. Connections originating from the new AWS platform may use different outbound IP addresses from those used by the existing Azure environment.
This may affect customer-managed:
​

Verodat will identify known affected connections and provide the required AWS IP addresses before the customer’s migration date.
Customers should ensure that the new addresses are permitted before cutover while retaining the existing Azure addresses until the migration has been completed and confirmed.
​

Verodat will migrate the existing customer environment, including:
​

The names of customer workspaces, datasets, mappings, rules, connections and other configuration items will remain unchanged.
Internal technical IDs will change.
​

Customer source files held in existing Azure, AWS or other customer-managed storage locations will remain where they are today.
Verodat will migrate the connection configuration and reconnect the new platform to the existing storage location. Customers will not normally be required to move or re-upload their historical source files.
Where a storage connection is protected by an IP allowlist, cloud-role trust policy, VPN or similar network control, a customer-side update may be required.
​

No. Existing data already written to a customer’s SQL Server or Snowflake environment will not be rewritten or removed as part of the migration.
Existing destination table names and output schemas are expected to remain unchanged unless a separate change has already been agreed with the customer.
New processing completed on the AWS platform will continue to write data to the configured destination.
​

Existing connection configuration will be migrated and tested.
Most connections should continue to work without a change to the logical configuration. However, customer action may be required where a connection depends on:
​

Verodat will review known customer connections and provide customer-specific guidance before migration.
​

Yes. Objects migrated into the AWS platform will be assigned new internal IDs.
This includes IDs associated with items such as:
​

For most users, this change will be transparent because the names and configuration presented in the Verodat interface will remain the same.
The change is important where an external integration, script, database process or saved URL directly references an internal ID.
​

Existing Upload IDs and Asset IDs already stored in customer destination systems will not be rewritten.
New uploads processed on the AWS platform will generate new IDs. These new IDs should be treated as separate identifiers from those generated by the Azure platform.
Customers should not assume that a new AWS-generated ID will be numerically greater than the last ID generated in Azure.
For example, a downstream process using logic such as:
​

may require a one-off adjustment at migration.
Depending on the process, the appropriate approach may be to:
​

Verodat will identify known downstream processes using Upload IDs or Asset IDs and agree the required cutover approach with the customer.
​

Customers should treat IDs as internal platform identifiers rather than as a permanent, globally sequential business key.
Where IDs are used outside Verodat, customers should ensure that they are not relied upon as the only cross-environment unique value. Verodat will review known integrations and advise where additional context, such as a date, source environment or another business key, should be used.
This is particularly important where historical Azure records and new AWS records are combined in the same downstream reporting or staging table.
​

Yes. Request endpoints contain internal platform IDs and will therefore change as part of the migration.
Verodat will provide replacement Request endpoint URLs for affected customers before migration.
Customers should:
​

Old Request endpoints should not be used after the customer’s migration has been confirmed as complete.
​

Yes. Automated email addresses that contain an internal Verodat identifier will change.
Verodat will identify active automated email addresses and provide replacement addresses before migration.
Customers may need to update:
​

Customers should continue using the existing address until the agreed cutover time and use the new address after migration.
​

API integrations may require changes where they reference:
​

The underlying API functionality and payload structure are not expected to change solely because of the infrastructure migration.
Existing API credentials and tokens are expected to remain valid in most cases, but Verodat will confirm this for each known active integration. Where a credential must be recreated or reauthorised, Verodat will provide instructions before migration.
Customers should complete a representative API test after cutover.
​

Bookmarks and deep links that contain the existing hostname or an old internal ID may no longer open the correct item after migration.
Users should access Verodat through:
​https://verodat.ai
and navigate to the relevant workspace, dataset or upload using its existing name.
Customers should update frequently used bookmarks and links in internal documentation.
Historical notification emails will remain in the customer’s email system, but links contained within those emails may point to the previous platform or an old object ID.
​

The AWS environment is intended to be hosted within the EU, and the migration will not change existing customer data-residency commitments.
Customer-managed source files will remain in their existing storage location. Data processed within Verodat will be handled in accordance with Verodat’s existing contractual, security and data-protection obligations.
The specific AWS region and any relevant data-residency documentation can be provided as part of the customer’s security review.
​

No. The migration does not change customer data ownership.
It also does not change:
​

The migration changes the underlying hosting infrastructure, not the ownership or permitted use of customer data.
​

The new platform is designed to provide a more standardised approach to security and operational management.
This includes controls relating to:
​

The migration is intended to strengthen Verodat’s ability to consistently operate and monitor these controls as the platform grows.
Customer-specific security documentation can be provided through the normal Verodat security review process.
​

Yes. Where required, Verodat’s hosting, security and subprocessor documentation will be updated to reflect the use of AWS.
The migration does not introduce a new purpose for processing customer data.
Customers that require an updated subprocessor list, data-flow description, security questionnaire or data-processing document should contact their Verodat representative.
​

The existing Azure environment will be retained for a limited contingency period following migration.
During this period, access will be restricted and the environment will not be used for normal customer processing unless required as part of an agreed contingency or rollback procedure.
Once the AWS migration has been confirmed as successful and the contingency period has ended, the relevant Azure environment and retained platform data will be securely decommissioned in accordance with Verodat’s data-retention and deletion procedures.
Customer-managed source files held in the customer’s own Azure storage account are not part of this decommissioning and will remain under the customer’s control.
​

Verodat will complete a structured set of checks before confirming that the environment is ready for normal use.
The checks are expected to include:
​

For customers with particularly important integrations or high-volume processing, additional customer-specific validation may be agreed.
​

Verodat will complete the primary technical validation.
Customers may also be asked to complete a focused business validation, such as:
​

The required customer checks will be included in the customer-specific migration plan.
​

Verodat will maintain a defined contingency and rollback process throughout the migration.
If the AWS environment does not pass the required validation checks, Verodat may:
​

The customer will be informed of any material issue and the agreed next step before normal processing resumes.
​

The AWS-based architecture is designed to provide more consistent and scalable processing performance, particularly as file sizes, file volumes and concurrent processing requirements increase.
Customers should benefit from improvements in areas such as:
​

The exact improvement will depend on file size, mapping complexity, validation rules, source and destination connectivity, and overall workload.
​

The infrastructure migration does not, by itself, change the customer’s Verodat subscription price, licence terms or support arrangements.
Customer-managed cloud services remain subject to the customer’s own agreement with its cloud provider. Where source files are held in customer-managed Azure storage and read by the AWS platform, standard cloud-provider network or data-transfer charges may apply depending on the customer’s Azure configuration and commercial agreement.
Verodat can review this with customers where material volumes are expected.
​

No change to normal Verodat support arrangements or agreed service levels is expected as a result of the migration.
During the migration itself, Verodat will provide direct communication covering:
​

Customers should:
​

Verodat will work with each customer to identify known affected integrations and connections.
​

Customers should contact their usual Verodat representative or the Verodat support team ([email protected]).
The customer-specific migration notice will also identify:
​