What would be the recommended Azure SQL configuration to move databases from On Premise server to Azure SQL database ?

Question

We have an on-premise server where it has 3 databases. The size of the databases are 0.01 GB, 0 GB and 0.02 GB respectively. We are expecting very little volume growth over time.

We would like to migrate it to Azure SQL database.

Should we choose Single database or Elastic pool under type in Azure SQL database ?

Please suggest Azure SQL specification for the migration including suggestions regarding the below features.

Region - Central India (Decided)

Type: Single Database or Elastic Pool ?

Purchase Model:

Service Tier:

Compute Tier:

Hardware Type:

Instance:

Disaster Recovery:

Redundancy:

Backup Storage Redundancy:

Answer 1

Hi @Subhasish Das

Thanks for the Question and using Microsoft Q&A platform

As per my understanding, you need configuration detail for your Databases.

the below recommendation might be suitable for your databases.

1. Region: Central India (Decided)

you’ve already decided on the region, this will be where your SQL Database or Elastic Pool is located.

2. Type: Single Database or Elastic Pool?

• Single Database: Opt for this if you need dedicated resources for a single database and expect consistent performance. Ideal for applications where database usage is predictable.
• Elastic Pool: Choose this if you have multiple databases with unpredictable or varying usage patterns. Elastic Pools allow sharing of resources like DTUs or vCores among databases, which can optimize cost if you have multiple databases with fluctuating demand.

    __Recommendation__: If you’re migrating multiple databases or expect resource demand to         vary over time, __Elastic Pool__ could be more cost-effective. If it’s a single high-demand               database, go with __Single Database__.
  

3. Purchase Model:

• Pay-As-You-Go: This is the most flexible and common model, where you pay based on usage.

    __Recommendation__: For most migrations, __Pay-As-You-Go__ is sufficient unless you know             your usage will be predictable and want to reduce costs.
  

4. Service Tier:

• Standard: Ideal for most production applications with moderate transaction rates and performance needs.

    __Recommendation__: For a typical enterprise production database, choose __Standard__
  

5. Compute Tier:

• DTU-based model (Data Transaction Units) – Best for workloads that need predictable performance based on a fixed number of DTUs.
• vCore-based model – Provides flexibility and scalability with CPU and memory configuration based on your needs. Recommendation: vCore-based offers better control over resources and is more suited for migrations due to its flexibility. Choose General Purpose for typical workloads.

6. Hardware Type:

• General Purpose: Suitable for most workloads, with balanced compute, memory, and storage options.

     __Recommendation__: General Purpose
  

7. Instance:

You can choose between different vCore sizes based on your workload:

• Small to Large instance sizes.
• Select the number of cores based on the number of concurrent users or applications that will be interacting with the database.

    __Recommendation__: Choose an instance that matches your anticipated load. For a                      production system, start with __4-8 vCores__ and adjust based on performance metrics.
  

8. Disaster Recovery:

Azure SQL provides automatic backup and geo-replication options:

• Geo-Replication: You can set up a geo-replica in a different region for disaster recovery.

    __Recommendation__: Enable __Geo-Replication__ for disaster recovery if your application                 requires high availability in case of regional failures.
  

9. Redundancy:

  Azure offers two main redundancy options:

• Zone Redundant: Keeps copies of your data across availability zones, which ensures higher availability and resiliency.
• Local Redundant: Data is replicated within a single data center.

    __Recommendation__: For __high availability__, select __Zone Redundant__ for automatic failover          to another zone if needed.
  

Please let me if the above information helpful or need any more details