We have a new community! Please visit support.timextender.com

Migrate Your TimeXtender Environment to Azure


This guide covers how to safely and efficiently migrate an on-premises TimeXtender application server and database platforms to Azure. After completing this guide, the TimeXtender application and services will be installed on a cloud-based Virtual Machine. The project repository and target SQL databases will be housed in an Azure PaaS database. For performance reasons, it is highly recommended your cloud databases are deployed in the same region as the cloud-based application server.

We strongly recommend that you use the Azure Marketplace apps for deploying TimeXtender to Azure. These plans include the TimeXtender Application Server for Azure, and it is deployed in a Virtual Machine on Azure that has been pre-configured to best support TimeXtender .

How to move from one server to the other

To move from one server to the other, use Microsoft’s Data Migration Assistant or Data Migration Service to migrate databases, schemas of databases, data and users, server roles, and SQL Server and Windows Logins. This is the best way to help you upgrade to your modern data platform because it is designed to enable seamless migrations to Azure data platforms with minimal downtime. It will also detect any compatibility issues that can impact database functionality. 

When migrating the TimeXtender application server and services, one of the most important pieces is to migrate the project repository database that contains all of metadata for your projects.

If you run into any issues with access or rights for users or service accounts on the new server, refer to the required Accounts and Permissions section at the bottom of this article.

  1. Create databases in Azure
  2. Migrate SQL Server Resources using DMA/DMS
  3. Configure the ODX Server
  4. Connect to the ODX Server
  5. Update ODX Storage
  6. Edit Analysis Services Endpoint (if applicable)
  7. Run the Connection Manager
  8. Update Multiple Environment Settings (if applicable)


1.  Create databases in Azure

In order to map your databases on your source server to the target server for migration, you must first create empty databases for them on Azure. 

  1. Using TimeXtender on your source server, adjust the connections so your target databases (e.g. MDW, ODX) point to your SQL Server on Azure.
  2. Click Create to have the database(s) created in Azure. 

3. Adjust the connection of your project repository so it points to your SQL Server on Azure.

4. Click Create to have the project repository created in Azure and click OK to close the dialogue box. 

5. When asked Do you want to save these changes before your project repository changes? Select Yes.

6. When asked Do you want to copy your current project to the new project repository?  Select No.


2. Deploy Your Project

Changing your server and database(s) will trigger a deployment., and TimeXtender will need to redeploy the raw and valid tables for those without incremental loads or history after changing the connection string.

3.  Migrate SQL Server Resources using DMA/DMS

  1. The next step is to migrate your project repository and target databases (e.g. ODX, DSA, MDW) to your Azure data platform using Microsoft’s recommended approach depending on your target server type. It is also recommended to migrate the schemas, data and users, server roles, and SQL Server and Windows logins associated with these databases.
  1. After you have successfully migrated databases, data and users, server roles, and SQL Server and Windows Logins associated with these databases, you need to start TimeXtender on the Virtual Machine on Azure.
  2. When you start TimeXtender for the first time you must enter in your license key and point it to the project repository in Azure.

*Ensure the user account has the proper permissions

4. When you open a project, edit the other target databases in your project to point to the new databases on Azure.

*Ensure the user account has the proper permissions

4. Configure the ODX Server

Before configuring the ODX server, ensure the ODX Server Service is not currently running on your current source server.

  1. In the Virtual Machine on Azure, open the ODX Server Configuration There is a shortcut located at “C:” or you can find it at “C:\Program Files\TimeXtender\ODX <version>”. This will open a wizard to help you configure the server and set up and start the Windows Service.
  2. In Step 1 of the wizard you will be asked for your Client Secret. You can find this by going to portal.timextender.com and clicking on the ODX tab. Once you have entered in your client secret, click Next in the ODX Server Configuration wizard.
  3. In Step 2 of the wizard, select your existing project or add a new one.
  4. In Step 3 of the wizard you are asked to specify a port number and maximum concurrent execution tasks. We recommend that you leave these at their default unless you have a reason to customize them. Click
  5. In Step 4 of the wizard you are asked to create the ODX management password and the TimeXtender connection password. Either keep the same password(s) or enter the new password(s) information and click
  6. In Step 5 of the wizard you can enter an encryption secret that is used when the encryption key is generated. Make sure to store the secret in a safe place since we cannot help you retrieve a lost secret. Enter in your encryption secret (16-32 characters) or use the system default encryption and click
  7. In Step 6 of the wizard you can specify what account you want to run the service as if you need to connect to SQL Servers using ActiveDirectory authentication. The user account needs to have the appropriate access on these servers. Specify the account or use the Local System Account and click
  8. In Step 7 of the wizard you can save your settings and start the ODX Server Service. Click Save.

5. Connect to the ODX Server

  1. Open TimeXtender and click Manage ODX Server on the Tools menu
  2. In the Manage ODX Server pane, right-click ODX Servers and click Add ODX…
  3. In the Name box, type a name for the ODX server (e.g. ODX)
  4. In the Server box, enter the ODX server address.
  5. In the Port box, enter the port number if it is different from the default
  6. In the Password box, enter the password for managing the ODX.
  7. Click OK.

6. Update ODX Data Storage

Once you are connected to the ODX Server, you must update your storage option if the deployment target for your ODX has changed. Only one storage option is allowed, and you can choose between SQL storage or an Azure Data Lake.

Adding SQL Server Storage: Azure SQL Database or Azure SQL Database Managed Instance

  1.  In the Manage ODX Servers window, right-click an ODX Server and click Add SQL Server Data Storage.
  2. In the Name box, type the name you want to use for the storage
  3. In the Server box, enter the address of server.
  4. Select SQL Server Authentication and type in the credentials
  5. Under Database type in name of your existing ODX database that was migrated over to Azure.
  6. Click OK to add the storage.

Adding Azure Data Lake Storage

Before adding an Azure Data Lake for storage, you must first register an application in order to access the data lake resources from TimeXtender. Find out how to create and register a new application here.

  1. Once your application has been registered, go to the Manage ODX Servers window, right-click an ODX Server and click Add Data Lake Data Storage.
  2. Name: type the name you want to use for the storage.
  3. Account Name: Use the name of your Data Lake Store. The input only needs the name of the resource instead of the entire URL.
  4. Folder name: Type the name of the folder you want to create. This folder doesn’t have to be created in Data Lake Store in advance. The root folder is always Operational data eXchange and this folder name will be under that.
  5. Analytics account name: Use the name of your Data Lake Analytics. This input only needs the name of the resource instead of the entire URL.
  6. Tenant ID: This is the [Directory ID] found under properties of Azure Active Directory.
  7. Application ID: Use the application you registered previously. The ID can be found under the registered app.
  8. Application Key: Use the key you created under the application.
  9. Analytics Unit: You pay for Analytics Units (AU) time used on your Azure subscription. Adding more AUs can increase performance on Incremental Load.
  10. Click OK to add the storage.

7. Azure Analysis Services (if applicable)

  1. If you have existing Analysis Services Tabular Endpoints in TimeXtender, edit the endpoint and point it towards your new server.


  • You can use the service account but only if it has rights on the Azure Analysis services server.
  • The Windows user that you use has to be added on the Analysis Services Admins.
  • If you are connecting to on-premises data sources, you will need to configure an on-premises data gateway to provide secure data transfer between on-premises data sources and your Azure Analysis Services servers in the cloud. Install and Configure On-Premises Data Gateway
  • If you are using Azure Analysis Services with Azure SQL Database Managed Instance, you must update your AAS configuration to work with Azure SQL Database Managed Instance. Azure Analysis Services integration with VNets via On-Premises Data Gateway


  1. If you have existing reports and dashboards in PowerBI that are connected to an on-prem SSAS Tabular Model, you can easily modify your Data source settings to point to your new Azure Analysis Server. This way you don’t have to rebuild all of your reports and dashboards.

8. Run the Connection Manager

Run the wizard in the connection manager to make sure all of your target databases have been updated, and then test your connections to make sure they are connected.

9. Update multiple environment settings (if applicable)

  1. After you have completed the first steps, you need to log into TimeXtender as the server services user.
  2. Point it to the other repository on the new server.
  3. Open the “Windows Service Setup”
  4. Start the Server Service as that user account and close the program.
  5. Open the program as the first user and open the “Environment Properties”.
  6. You should be able to see all environments and global databases.
  7. Deploy and execute all projects.

Additional Information

Accounts and Permissions

Ensure the users, user groups, and service accounts have the same access and rights to the new server. Below are the access and rights required.

User Accounts

Identify and/or create the following user accounts. Azure Active Directory (AAD), is recommended if using the Hybrid or Cloud configurations but the permissions are the same for local Active Directory (AD). If utilizing Azure Analysis Services then Azure Active Directory is required.  

  1. One user account for each TimeXtender developer. 
  2. One Service Account must be created for each “non-development” environment. These will be used to run the TimeXtender Multiple Environment and Scheduler Services.

Security Group

Create an Active Directory (AD) Security Group called TXDevelopers and add the developer user accounts. This will make it easier to apply permissions as developers work on and off the project.

Application Server

Local or Domain Administrator on the Application Server. This is required to be able to start and stop services.

Database Permissions

  • Azure SQL Database permissions
    • Data sources: db_datareader
    • Target databases: Server admin, Azure Active Directory admin or dbmanager role in the master database. If hosting the project repository in Azure SQL DB then a SQL account is required. If using contained database users, then use the db_owner role.
  • Azure SQL Database Managed Instance permissions
    • Data Sources: db_datareader
    • Target databases: sysadmin or dbOwner. Note that if using dbOwner instead of sysadmin, a user account with at least dbCreator rights must log in and create the project repository database from within the project repository settings dialog.
  • Azure Analysis Services
    • Analysis Services Admin permissions based from an Azure Active Directory login.



There are alternative methods for moving the application server. You can view other methods here.

Was this article helpful?
0 out of 0 found this helpful


Please sign in to leave a comment.