Multiple Environments¶

How to create and configure environments, and migrate between them, so deployments across your organization are accurate, secure and traceable.

In this module: configuring multiple environments · instance migration · instance documentation · data lineage · meta collections

Why multiple environments?¶

Working in a single environment might seem simpler at first, but it creates significant risks as your organization becomes more dependent on data for critical business decisions. When changes are made directly to production data, you risk business disruption from broken data pipelines, or incorrect decisions based on wrong data — and a loss of trust in your data solutions.

A multi-environment setup eliminates these risks by creating controlled spaces for development, testing and production, so changes and experimentation happen safely without affecting business-critical reports.

Maintaining identical copies of every data layer can be expensive and isn't always necessary. Timextender's modular, cloud-based instances enable flexible multi-environment topologies based on your organization's needs.

Example environment configuration¶

In the diagram above:

• Development and Production each have their own complete data pipeline (Ingest → Prepare → Deliver).
• The Test environment receives data from Development's Ingest storage.
• This provides "just enough" data validation without excessive duplication.
• It reduces storage costs while maintaining proper testing protocols.

Configure multiple environments¶

Use the Portal to add distinct environments for Development, Test and Production, and provision separate instances for each. Not all instances must use multiple environments, but you must have at least two of any instance type to use environment migration.

Create environments¶

1. In the Portal, go to Data Estate → Instances → Environments → Create.
2. Create the DEV, TEST and PROD environments.

Add instances to environments¶

1. In the Portal, go to Data Estate → Instances.
2. Select the instance, drag it and release it onto the target environment.

Follow a migration procedure¶

If done improperly, migrating environments can introduce unwanted issues into your production environment. Defining and following an environment migration procedure ensures the proper steps are followed each time. The example below is a starting point — adjust it to align with your IT policies.

1. Pre-promotion validation — confirm DEV tests are complete, dependencies are present, and report impacts are assessed.
2. Controlled migration — ensure the target environment is idle, stop execution services to avoid conflicts, and run the migration with detailed comments.
3. Post-promotion verification — validate changes immediately via reports or dashboards, monitor logs, and confirm full data loads.
4. Final sign-off and archiving — collect stakeholder approval, communicate release completion, and attach artifacts to change records.

Instance environment migration¶

Before migrating from DEV to TEST, ensure all related work items are completed, saved and annotated with clear version notes. If your change set includes incremental tables with new fields or transformations, prepare a promotion-specific execution package during development that can be run in the target environment after promotion.

1. From the Portal, navigate to Data Estate → Migrations.
2. Click the arrow next to the instance you wish to migrate.
3. Select the target environment and target instance.
4. Click Next.
5. Map the appropriate Ingest instance and click Next.
6. Review and migrate.

Export deployment steps¶

After migrating your instance, and before you deploy any changes, Timextender makes it easy to document exactly what changed — for compliance, and for root-cause analysis in later troubleshooting. This export becomes your auditable record, showing scope, order and rationale for every change.

Export deployment steps from the Prepare instance¶

1. In Solution Explorer, right-click the Prepare instance.
2. Hover Advanced → select Export Deployment Steps.
3. Under File type, choose CSV and check Open file after save.
4. Click Export/OK and save the file.
5. Open it, review the order and scope, then distribute to stakeholders or attach it to change records.

Deploy and execute in the target environment¶

Promoting changes into a new environment should never mean redeploying everything. Full deployments take longer, introduce unnecessary risk, and may update objects beyond the intended sprint scope. Focus only on the changes and scope you deliberately planned — that keeps your environment stable, your deployments predictable and your testing faster.

Differential deployment¶

1. In the Prepare instance, right-click → Deploy.
2. Ensure Enable differential deployment is selected. Click Review Tasks.
3. Review the pending change list and confirm scope. Click Start.

Perspective deployment¶

If you have made changes outside your sprint scope and would prefer not to deploy them, rely on the sprint perspective to deploy only the objects you want.

1. In Solution Explorer, identify the perspective for your sprint scope.
2. Right-click → Deploy.
3. Ensure Enable differential deployment is selected. Click Review Tasks.
4. Confirm only scoped objects are included. Click Start.

Execute your promotion-specific package¶

Once deployment is complete, execute the promotion-specific execution package you prepared during development. This ensures any impacted tables — particularly those requiring full loads — are refreshed immediately in the target environment. Without this step, your validation in TEST or PROD may be based on incomplete or stale data.

Related reference¶

• Agile Team Development — building the promotion plan during the sprint.
• Scheduled Executions — creating the packages you run after promotion.
• Portal — where environments and migrations live.