Overview
Migration is the cross-product feature for moving artifacts — Reports, Custom Scripts, Data Models, and Workflows — between Datanyx accounts or environments. The feature has two complementary surfaces accessed from the Migration icon on the Main Navigation Bar: the Migration Plan tab, where plans are created, listed, and downloaded; and the Migration tab, where plans are imported into the current environment with a Configuration Template applying source-to-local ID mappings.
Migration Plans created in an environment are visible to all admin users in that environment. The downloadable plan file can be imported into another environment either by selecting the source environment from a dropdown (when both environments are reachable) or by uploading the previously downloaded file. The Configuration Template translates between source-environment IDs and destination-environment IDs for the artifacts that reference Datasources and Connectors.
When to use it
- Promoting tested artifacts from a development environment to production.
- Cloning a Report, Workflow, or Data Model from one project to another within the same environment, or across environments.
- Backing up artifacts as portable Migration Plan files for archival or audit purposes.
- Replicating configurations across multiple destination environments (use the same plan, different Configuration Templates per destination).
- Sharing artifacts across organization environments where direct cross-environment links aren’t available.
Two surfaces, one feature
The Migration screen exposes two tabs that together implement the export and import sides of cross-environment artifact movement.
| Migration Plan | Lists existing plans and creates new ones. Plans bundle Reports, Custom Scripts, Data Models, and Workflows into a downloadable file. Plans are visible to all admin users in the current environment. |
| Migration | Imports a Migration Plan into the current environment. Supports both reachable-environment imports (selecting a source environment from a dropdown and picking a plan) and downloaded-file imports. Applies a Configuration Template to map source IDs to local IDs. |
Artifact types
A Migration Plan can include any combination of four artifact types. None is mandatory — a plan can ship any one type, all four, or any subset.
| Reports | Lens visualizations and configured chart/dashboard definitions. Includes the Report’s chart configuration, data binding, filters, and layout. |
| Custom Scripts | Platform-wide scripted artifacts (the platform’s term for what some users call “data cubes”). |
| Data Models | Schema or data structure definitions used by Reports and Workflows. |
| Workflows | Weave pipelines, presented in the UI as Workflows. |
Migration Plan creation
Plans are created via a step-by-step pop-up with a fixed sequence of selection screens.
| 1. Title and Description | Name the plan and provide context about its purpose, source environment, and destination. |
| 2. Reports | Select Reports to migrate. Search bar narrows the list. Checkbox selection. |
| 3. Custom Scripts | Select Custom Scripts to include. |
| 4. Data Models | Select Data Models to include. |
| 5. Workflows | Select Workflows to include. |
| 6. Preview | Review all selected artifacts grouped by type. Use Previous to step back and adjust; Submit to finalize. |
Plan creation skips no steps — even if an artifact type isn’t being migrated, the corresponding step still appears with an empty selection. Submitting the plan creates a downloadable file with whatever artifacts were selected.
Configuration Template
Configuration Templates control how source-environment IDs map to destination-environment IDs during import. They’re required because artifacts reference Datasources and Connectors by ID, and those IDs differ between environments. The template stores the mapping for reuse across multiple imports.
| Title | Name identifying the template. Reusable across multiple imports. Descriptive titles help — e.g., “Prod EU”, “Staging US,” or “Dev → Prod (Q3)”. |
| Migration Source Environment | The environment the plan was exported from. |
| File Type | Datasource ID or Connector ID — picks which kind of ID the template’s mapping applies to. |
| Source ID | The ID in the source environment (Datasource ID or Connector ID, depending on File Type). |
| Local ID | The corresponding ID in the destination environment. This is the ID artifacts should reference after import. |
| Input mode toggle | Each field can be entered manually via input box OR selected from a dropdown of available IDs. Toggle between modes per field. |
| Multiple artifact mappings | A single template can map multiple Source ID → Local ID pairs covering all artifacts in the plan. |
Import options
After picking the project and template, the Migration Plan itself is supplied through one of two methods.
| Environment selector | Pick the source environment from a dropdown, then select the desired plan from the list of plans available on that environment. Use when the source environment is directly reachable from the destination. |
| Choose File | Upload a previously downloaded plan file from a local folder. Use when the source environment isn’t directly reachable (cross-account migrations, migrations from a backup archive, transferring plans via shared storage). |
Notes are optional and are stored alongside the migration log. They’re visible to other users in the same organization and environment when reviewing migration history.
Key behaviors
Plans are environment-scoped. Migration Plans appear on the Migration Plan tab only for the environment they were created in. Plans created in a different environment are not visible — to migrate them in, either select the source environment from the import dropdown (if reachable) or upload the downloaded plan file. This scoping prevents accidental cross-environment plan modifications.
Plan composition is optional per artifact type. A plan can include any combination of Reports, Custom Scripts, Data Models, and Workflows. Selecting under each step is not mandatory — empty selections produce a plan that ships fewer artifact types, which is valid. Designers should still proceed through each step (the step doesn’t auto-skip).
Configuration Templates are reusable. Templates persist across migrations. A team migrating from a Dev environment to a Production environment configures the Dev → Prod template once and reuses it for every subsequent migration. Multiple templates can target different destinations from the same source environment.Source ID and Local ID together identify a mapping. The Configuration Template doesn’t auto-detect ID equivalences — Designers must explicitly specify which Source ID in the exported plan corresponds to which Local ID in the destination. Getting this wrong produces imported artifacts that reference the wrong Datasource or Connector.