Share via

Best Approach to Move Selected Azure Resources Between Dev and Prod Subscriptions

SYN 125 Reputation points
2026-05-14T05:35:38.22+00:00

Hi Everyone,

I currently have a Dev Azure subscription containing the following resources:

Azure Data Factory with 100 pipelines

Azure SQL Database with:

150 tables

100 stored procedures

20 views

10 functions

10 Logic Apps

ADLS Gen2 storage account

Azure Key Vault

Now I want to move/copy only selected resources from Dev subscription to Production subscription. Additionally, I may also need to move some resources from Production back to Dev for testing and synchronization purposes.

Resources required in Production:

50 ADF pipelines

100 SQL tables

50 stored procedures

10 views

5 functions

5 Logic Apps

ADLS storage/data

Required Key Vault secrets/configurations

Both the Dev and Prod subscriptions are under the same Azure tenant.

I would like guidance on the best optimized and enterprise-recommended approach for:

1.Migrating only selected ADF pipelines between environments

2.Moving/copying only specific SQL objects and related data

3.Migrating selected Logic Apps

4.Copying/synchronizing ADLS data efficiently

5.Migrating Azure Key Vault secrets and managing environment-specific configurations

6.Handling bidirectional movement between Dev and Prod when needed

7.Setting up CI/CD or deployment automation

8.Minimizing downtime and avoiding manual work

9.Best practices for Production environment setup

10.Whether resource move or recreate + deploy approach is better

Would appreciate any real-world suggestions, architecture recommendations, or lessons learned from similar implementations.

Thanks in advance!

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manoj Kumar Boyini 14,900 Reputation points Microsoft External Staff Moderator
    2026-05-17T08:21:58.8366667+00:00

    Hi SYN

    For your scenario, the recommended enterprise approach is to use Infrastructure-as-Code (IaC) and CI/CD-based deployments rather than directly moving Azure resources between subscriptions. This provides better repeatability, governance, rollback capability, and environment consistency.

    Below is the recommended approach for each component:

    1. Azure Data Factory (ADF)

    • Enable Git integration only on the Dev Data Factory.
    • Use ARM templates/Bicep generated from the collaboration branch for deployments.
    • Deploy selectively to Production using CI/CD pipelines (Azure DevOps or GitHub Actions) with parameterized configurations for linked services, Key Vault references, and triggers.
    • For selective deployment of pipelines, organize workloads modularly (for example by domain/project/folder) rather than manually moving pipelines individually.
    • Microsoft recommends ARM/Bicep-based deployment over direct resource moves for ADF promotion scenarios.

    2. Azure SQL Database

    • Use SSDT/SQL Database Projects with DACPAC/SqlPackage for schema deployment (tables, procedures, views, functions).
    • Treat schema deployment separately from data movement.
    • Use ADF Copy Activity, BCP, or export/import mechanisms for selective data migration.
    • Avoid using geo-replication for selective object movement, as it replicates the full database.

    3. Logic Apps

    • Deploy Logic Apps using ARM templates/Bicep/Terraform with environment-specific parameters.
    • Store connection references and secrets externally through Key Vault.
    • Direct “resource move” operations are better suited for full-resource migration, not selective workflow promotion.

    4. ADLS Gen2

    • Use AzCopy (azcopy sync) or ADF Copy Activity for incremental synchronization between environments.
    • For ongoing synchronization, orchestration through ADF pipelines is preferred.

    5. Azure Key Vault

    • Maintain separate Key Vaults per environment (Dev/Prod).
    • Use deployment parameterization and environment-specific secret references.
    • Use backup/restore only when specific secrets/keys need migration.

    6. Dev ↔ Prod Synchronization

    • Enterprise best practice is primarily one-way promotion (Dev → Test → Prod) to avoid configuration drift.
    • If Prod → Dev synchronization is required for testing or hotfix validation, automate it carefully and avoid manual copying.

    7. CI/CD & Automation Recommended architecture:

    • Source control repository (Git)
    • IaC templates (ARM/Bicep/Terraform)
    • Azure DevOps or GitHub Actions deployment pipelines
    • Environment-specific parameter files
    • Automated validation and deployment stages

    8. Minimizing Downtime

    • Use deployment slots/staged rollouts where applicable.
    • Disable ADF triggers during deployment and re-enable afterward.
    • Use online-compatible database schema changes.
    • Schedule production cutovers during low-traffic windows.

    9. Production Best Practices

    • Separate subscriptions/resource groups per environment
    • RBAC separation and least privilege access
    • Key Vault-backed secrets/configuration
    • Centralized monitoring/logging
    • Azure Policy and tagging governance
    • Resource locks for critical production assets

    10. Move vs Recreate + Deploy

    • Azure resource move operations are typically “all-or-nothing” and are best suited for full-resource relocation.
    • For selective deployment, repeatability, auditing, rollback, and long-term maintainability, recreate + deploy through IaC/CI/CD is the preferred enterprise model.

    References:

    Please let us know if you have any additional questions.

    Was this answer helpful?

  2. AI answer

    2026-05-14T05:36:10.58+00:00

    For this scenario, the enterprise-recommended pattern is to treat Dev and Prod as separate environments and use deployment automation (ARM/Bicep, Azure DevOps/GitHub, etc.) to recreate and deploy only the selected resources, rather than relying on ad‑hoc “move” operations.

    Within the provided information, the following guidance applies:

    1. Migrating only selected ADF pipelines between environments
      Azure Data Factory CI/CD is based on Azure Resource Manager (ARM) templates. ADF entities (pipelines, datasets, data flows, etc.) are stored as ARM resources and promoted between environments using:
    • Automated deployment with Azure Pipelines, or
    • Manual upload of ARM templates via the Data Factory UX.

    To move only selected pipelines:

    • Export an ARM template from the Dev factory that contains all entities.
    • Edit the template (or maintain separate templates) so that only the required pipelines and their dependent datasets/linked services are included.
    • Deploy that template to the Prod subscription using Azure Pipelines or the ADF UX.
    1. Moving/copying only specific SQL objects and related data
      The context does not provide SQL‑specific migration details beyond general ARM/relocation guidance, so no additional prescriptive steps can be added here.
    2. Migrating selected Logic Apps
      Logic Apps are also ARM‑based resources. For moving Logic Apps between regions or subscriptions, the recommended approaches are:
    • Recreate the Logic App in the target environment and copy the workflow definition and connections from the source Logic App using Code view in the designer.
    • Or, export the Logic App as an Azure Resource Manager template and deploy it to the target subscription. The template includes the workflow and connections, with parameters for environment‑specific values.

    When moving only selected Logic Apps:

    • Export or script only those Logic App resources (and their connections) into ARM templates.
    • Deploy those templates to the target subscription and re‑authorize connections as needed.
    1. Copying/synchronizing ADLS data efficiently
      For data relocation, the guidance includes using Azure Data Factory pipelines as a data‑relocation automation tool:
    • ADF pipelines can orchestrate and automate movement and transformation of data, including between storage accounts and regions.
    • Use ADF copy activities to move/synchronize only the required folders/files between Dev and Prod ADLS accounts.
    1. Migrating Azure Key Vault secrets and managing environment-specific configurations
      The context notes that some services (like Key Vault) require manual backup and restore as part of region or environment relocation. For Key Vault:
    • Follow service‑specific relocation guidance (for example, “Move Key Vault to another region”) and apply the same pattern between subscriptions.
    • Use backup/restore or scripted export/import of secrets, with separate vaults per environment and environment‑specific values.
    1. Handling bidirectional movement between Dev and Prod when needed
      The recommended pattern is not to “move back” production resources into Dev, but to:
    • Treat Dev as the source of truth for infrastructure and application definitions (ARM templates, pipelines, Logic Apps, etc.).
    • Use the same deployment automation to deploy from Dev to Prod and, when necessary, to refresh Dev from a known template or backup.

    For data, use ADF pipelines or other supported tools to copy subsets of data from Prod to Dev when required, following data‑relocation automation guidance.

    1. Setting up CI/CD or deployment automation
      For ADF:
    • Use Azure Pipelines integration with ADF for CI/CD. ADF uses ARM templates to store configuration of pipelines, datasets, and other entities, and these templates are deployed via Azure Pipelines.

    For Logic Apps and other ARM‑based resources:

    • Use ARM templates and Azure Pipelines (or other CI/CD tools) to deploy to multiple environments, parameterizing environment‑specific values (connection strings, endpoints, Key Vault references, etc.).
    1. Minimizing downtime and avoiding manual work
      ARM‑based deployments and ADF CI/CD help minimize downtime by:
    • Automating deployments and avoiding manual portal changes.
    • Allowing staged deployments (Dev → Test → Prod) with repeatable templates.

    For region or environment moves where Resource Mover is not supported, the guidance is to redeploy resources using ARM templates and service‑specific relocation guidance, which aligns with the recreate + deploy pattern.

    1. Best practices for Production environment setup
      Relevant best practices from the context include:
    • Separate environments for Dev, Test, and Prod for healthy ALM.
    • Use solutions/ARM templates and DevOps automation to ship changes across environments.
    • Use Azure landing zone and relocation guidance to plan resource moves, including assessment of RBAC and policies when moving subscriptions or resource groups.
    1. Whether resource move or recreate + deploy approach is better
      For cross‑subscription and cross‑region scenarios, the guidance is:
    • Use Azure Resource Mover where supported to move entire resources across regions with dependency analysis and orchestration.
    • For services not supported by Resource Mover, or when only selected resources are needed, use manual redeployment via ARM templates and service‑specific relocation guidance.

    Given the need to move only selected pipelines, Logic Apps, and data, and to support ongoing CI/CD, the recreate + deploy approach using ARM templates and ADF CI/CD is the recommended enterprise pattern.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.