Seconds of Downtime, Hours of Confusion: Handling Transient Azure SQL Disconnects
A database can recover in seconds while an application remains unavailable for much longer. Brief connectivity interruptions are expected failure modes that cloud applications should be designed to tolerate. With Azure SQL Database, transient connectivity errors can occur during short-lived service reconfiguration events. Microsoft notes that many such reconfiguration events complete in less than 60 seconds and recommends that applications implement retry logic rather than immediately surfacing transient failures to users. But the database interruption is only part of the story. An application might continue experiencing problems because of: Failed connections. Lost in-flight operations. Retry behavior. Connection-pool recovery. Authentication or token issues. Queued requests. Application instances retrying simultaneously. Backlogs that must drain after connectivity returns. This leads to an important troubleshooting principle: Database recovery and application recovery are separate milestones. Understanding that difference can turn a confusing availability incident into a defensible timeline and, more importantly, a more resilient application design. 1. Transient Does Not Mean Harmless A transient interruption is temporary, but its application impact doesn't have to be. Consider a simplified timeline: Time Event T0 Application healthy T1 Database connectivity is interrupted T2 Database connectivity becomes available again T3 Applications reconnect T4 Request backlog begins draining T5 Application returns to normal The actual database connectivity event is: T1 → T2 But users might experience impact across: T1 → T5 Calling the entire T1-to-T5 period a continuous database outage would be inaccurate unless evidence proves that the database itself remained unavailable. Instead, investigate the periods separately. 2. Build a Three-Layer Timeline A good post-incident investigation should correlate three timelines. Layer 1: Database/connectivity behavior Capture: Connection failures. Successful reconnections. Relevant Azure monitoring signals. Azure Service Health information when applicable. Database resource behavior. Layer 2: Client connectivity Capture: SQL exception number. Exception timestamp in UTC. Connection timeout. Retry attempts. Retry delays. Authentication failures. Network errors. Azure SQL troubleshooting guidance recommends logging failure timestamps and notes that SQL Database can return tracing information helpful during connectivity investigations. Layer 3: Application recovery Capture: Application health. Request failures. Queue depth. Retry volume. Connection-pool recovery. Backlog drain time. Time when users actually recovered. The timelines might reveal: Database connectivity restored │ ▼ Applications reconnect │ ▼ Backlog continues │ ▼ Application fully recovered That distinction is essential. 3. Classify the Failure Before Retrying It Not every SQL connectivity error means the same thing. Classify the symptom into categories such as: Transient availability/connectivity failure. Authentication failure. Token-related failure. Network-path problem. DNS problem. Firewall/configuration issue. Resource-governance condition. Application timeout. Long application recovery after SQL connectivity returns. Azure SQL Database documents multiple connectivity failure categories, including transient fault errors such as 40197 and 40613, authentication failures such as 18456, network termination conditions, firewall issues, and connection timeouts. The classification matters because: Not every failure should be retried in the same way. 4. Use Azure SQL Connectivity History Carefully Azure SQL Database exposes connectivity-event information through system views in the logical server's master database. One useful view is: sys.database_connection_stats It provides aggregated connection success and failure information in five-minute intervals. Connect to the logical server's master database and run: DECLARE @StartTime datetime2 = DATEADD(HOUR, -2, SYSUTCDATETIME()); SELECT database_name, start_time, end_time, success_count, total_failure_count, connection_failure_count FROM sys.database_connection_stats WHERE start_time >= @StartTime ORDER BY start_time DESC; This can help answer: Did connection failures occur? Which database was affected? In which five-minute interval? Were successful connections also occurring? But there's an important limitation. This is aggregated historical information, not a second-by-second outage trace. The data can also arrive later, with Microsoft documenting that it can take up to 24 hours for all information to appear. Therefore, don't use one five-minute bucket containing failures to claim: "The database was unavailable for five minutes." The evidence only tells you connection failures were recorded during that interval. 5. Look Deeper With sys.event_log For additional connectivity-event information, Azure SQL Database exposes: sys.event_log This view records successful database connections and connection failures and is intended to help track and troubleshoot Azure SQL Database connectivity activity. Again, connect to master. DECLARE @StartTime datetime2 = DATEADD(HOUR, -2, SYSUTCDATETIME()); SELECT database_name, start_time, end_time, event_category, event_type, event_subtype, event_subtype_desc, severity, event_count, description FROM sys.event_log WHERE start_time >= @StartTime AND event_category = N'connectivity' ORDER BY start_time DESC; Useful columns include: start_time end_time event_category event_type event_subtype_desc severity event_count description Microsoft cautions that querying sys.event_log can consume significant resources on logical servers with many databases or high login volumes, so keep the time range and other filters appropriately narrow. 6. Correlate SQL Evidence With Application Errors Now correlate the Azure SQL evidence with client telemetry. For every important application-side SQL exception, capture: UTC timestamp. SQL error number. Error message. Application instance. Operation. Retry attempt. Retry delay. Final outcome. Correlation or request ID when available. For example: UTC Layer Observation 10:00:02 Application SQL connection exception 10:00:04 Application Retry 1 fails 10:00:08 Application Retry 2 fails 10:00:15 SQL Connectivity succeeds 10:00:18 Application New connection succeeds 10:01:30 Application Queue still processing 10:05:00 Application Normal service restored Now you can separate: Connectivity interruption. Reconnection period. Application recovery period. That's substantially more useful than describing the full period as: "SQL was down." 7. Understand Connectivity and Reconfiguration Applications connect to the Azure SQL Database gateway, after which traffic is handled according to the effective connection policy and directed to the appropriate database environment. In a managed database service, applications must be designed for transient connectivity interruption. Microsoft specifically describes transient faults as conditions whose underlying cause resolves itself and notes that service reconfiguration can temporarily affect database connectivity. The application therefore shouldn't depend on one connection remaining valid indefinitely. Design for: Connections occasionally being terminated. New connection attempts occasionally failing. In-flight work requiring recovery. DNS and network paths needing to remain correctly configured. Authentication credentials or tokens remaining valid. Retry behavior that allows the system time to recover. Avoid guessing at undocumented platform internals when investigating an event. If evidence establishes only: "Connections failed briefly." Don't convert that into an unsupported explanation of why the platform changed state. 8. Retry Smartly, Not Aggressively Retry logic is essential for cloud applications that connect to Azure SQL Database. Microsoft explicitly recommends retry logic for transient connection failures. But a retry strategy needs boundaries. A good strategy considers: Number of attempts. Delay between attempts. Increasing delay. Random jitter. Maximum interval. Total retry budget. Whether the operation can safely be repeated. A bad strategy looks like: Failure ↓ Retry immediately ↓ Failure ↓ Retry immediately ↓ Failure ↓ Retry immediately... Across hundreds of application instances, this behavior can make recovery harder. A better pattern is: Failure ↓ Wait + jitter ↓ Retry ↓ Longer wait + jitter ↓ Retry ↓ Stop after bounded attempts 9. Use Microsoft.Data.SqlClient Retry Logic For .NET applications using Microsoft.Data.SqlClient, configurable retry logic is available in version 3.0 and later. Microsoft documents providers for configuring connection and command retries. A connection retry provider can be configured like this: var options = new SqlRetryLogicOption() { NumberOfTries = 5, DeltaTime = TimeSpan.FromSeconds(1), MaxTimeInterval = TimeSpan.FromSeconds(20) }; SqlRetryLogicBaseProvider provider = SqlConfigurableRetryFactory.CreateExponentialRetryProvider(options); using var connection = new SqlConnection(connectionString); connection.RetryLogicProvider = provider; connection.Open(); With this configuration: NumberOfTries = 5 Allows one initial attempt and up to four retries. DeltaTime Influences the delay between attempts. MaxTimeInterval Caps an individual retry delay. The exponential provider adds randomized jitter to retry intervals. The actual values should be tested against your application's: Latency requirements. Failure budget. Traffic volume. Concurrency. User experience. They're not universal service recommendations. 10. Connection Retry and Command Retry Are Different This is one of the most important resiliency distinctions. Suppose this fails: connection.Open(); Retrying the connection after an appropriate delay is generally straightforward for a transient connection condition. But suppose this fails: UPDATE dbo.Orders SET ProcessingStatus = N'Completed' WHERE OrderID = @OrderID; The application now has a harder question: Did the UPDATE execute before the connection was lost? Blindly repeating the command isn't always safe. Microsoft's Azure SQL guidance recommends establishing a fresh connection after a transient command failure before retrying, and retry logic must correctly account for the transaction's outcome. 11. Idempotency Matters Different operations require different retry treatment. Read-only operation For example: SELECT OrderID, ProcessingStatus FROM dbo.Orders WHERE OrderID = @OrderID; Repeating a read is often relatively straightforward, subject to your application's consistency requirements. Update operation For example: UPDATE dbo.Orders SET ProcessingStatus = N'Completed' WHERE OrderID = @OrderID; The client must determine whether repeating this operation is safe. Insert operation Consider: INSERT dbo.PaymentRequests ( RequestID, AccountID, Amount ) VALUES ( @RequestID, @AccountID, @Amount ); If the connection disappears after the server commits but before the client receives confirmation, an unconditional retry could create duplicate business activity unless the application and schema provide an idempotency mechanism. For example, a unique request identifier can make duplicate detection possible. The important principle is: Retryability is a business-operation property, not simply a SQL error property. 12. Transactions Need Special Treatment Be particularly careful with multi-statement transactions. Consider: BEGIN TRANSACTION; UPDATE dbo.Inventory SET Quantity = Quantity - @Quantity WHERE ProductID = @ProductID; INSERT dbo.ShipmentQueue ( RequestID, ProductID, Quantity ) VALUES ( @RequestID, @ProductID, @Quantity ); COMMIT TRANSACTION; If connectivity is interrupted, don't simply reconnect and retry the last statement. Your application needs a strategy that protects the integrity of the entire unit of work. Microsoft's retry documentation specifically cautions that if a transient failure invalidates an active transaction, the application should retry the entire transaction rather than only the failed statement. 13. Prevent the Retry Storm Imagine 500 application instances lose connectivity simultaneously. If every instance retries immediately: 500 requests fail ↓ 500 immediately retry ↓ Another synchronized wave ↓ Another synchronized wave Recovery traffic itself can become disruptive. Exponential backoff with jitter helps spread retries across time instead of concentrating them into synchronized bursts. The configurable retry provider in Microsoft.Data.SqlClient supports exponential retry behavior with randomized jitter. Also consider application-level resilience mechanisms such as: Circuit breakers. Back-pressure. Queueing. Controlled concurrency. Connection-pool recovery. Rate limiting. Load shedding where appropriate. The objective isn't: "Retry until SQL succeeds." It's: Recover gracefully without creating a second problem. 14. Don't Ignore the Network Path Not every SQL connection failure originates from the database. Azure SQL Database connectivity includes several components between the application and database, with connection behavior also influenced by the configured connection policy. Troubleshooting may need to include: DNS. Firewall configuration. Private endpoints. Network security rules. Client outbound connectivity. Connection policy. Authentication. Application host health. Azure SQL supports Redirect, Proxy, and Default connection-policy configurations depending on the environment and configuration. In Redirect mode, clients establish connections directly to the node hosting the database after the initial gateway interaction, which requires appropriate network access. This is another reason not to classify every connection exception as: "Azure SQL outage." 15. Test Resiliency Before an Incident Don't wait for a real platform event to discover whether your application's recovery logic works. Test controlled failure scenarios involving: New connections. Existing connections. Read-only requests. Writes. Multi-statement transactions. Multiple application instances. Queued workloads. Connection pools. Measure: Time to detect failure. First retry delay. Number of attempts. Time to establish a new connection. Failed user requests. Queue growth. Queue drain time. Full application recovery. The real success metric isn't merely: "Can I connect to the database again?" It's: "How quickly can the application return to normal service without compromising correctness?" 16. Write a Defensible Post-Incident Report A strong post-incident report separates facts, inferences, and unknowns. Confirmed facts Examples: Client connection failures were recorded during a specific UTC interval. Successful connections later resumed. Certain client instances continued failing after initial connectivity returned. Application backlog persisted beyond the connectivity event. Retry activity increased during recovery. Supported inference Example: Aggressive retry behavior likely contributed to slower application recovery. Use this classification only when application telemetry supports the relationship. Unknowns Examples: The exact internal platform operation responsible for a transient event. Whether an unrelated network event contributed. Whether a capacity change affected recovery. Don't fill gaps in telemetry with assumptions. 17. A Practical Decision Tree When an application reports an Azure SQL connectivity incident: 1. Is the database reachable now? No Check current Azure status and application connectivity. Validate networking, DNS, firewall, authentication, and Azure SQL availability. Yes Continue reconstructing the historical incident. 2. Did Azure SQL record connection failures? Yes Correlate: sys.event_log. sys.database_connection_stats. Application timestamps. Azure monitoring evidence. No or evidence isn't yet available Continue investigating application and network telemetry. Remember that historical connectivity data can arrive later. 3. Did the application retry? No Implement a bounded transient-fault handling strategy. Yes Evaluate: Retry count. Delay. Backoff. Jitter. Error classification. 4. Did many instances retry simultaneously? Yes Investigate: Retry synchronization. Circuit breaking. Back-pressure. Queue recovery. Connection pools. 5. Were writes or transactions interrupted? Yes Validate: Transaction outcome. Idempotency. Duplicate prevention. Whole-transaction retry behavior. 6. Did the application remain unhealthy after connections succeeded? Yes Measure application recovery separately from the original database connectivity event. Final Takeaway The hardest part of a transient Azure SQL event isn't always the interruption itself. Sometimes it's the application's response. A resilient architecture recognizes three separate timelines: Connectivity interruption Database/connectivity recovery Application recovery Azure SQL Database is designed as a cloud service where applications should expect and tolerate transient connectivity conditions. Microsoft recommends implementing retry logic rather than exposing appropriate transient failures directly to users. But resilient retry logic must be: Bounded. Delayed. Appropriately randomized. Error-aware. Transaction-aware. Idempotency-aware. Observable. And post-incident analysis should distinguish: What is confirmed. What is inferred. What remains unknown. Because: A brief database disconnect doesn't have to become a prolonged application outage. The objective isn't to design an application that never experiences a disconnected connection. The objective is to design an application that absorbs the interruption, recovers safely, and returns to normal operation predictably. Further reading Working with Transient Errors in Azure SQL Database Troubleshoot Common Connection Issues in Azure SQL Configure Retry Logic in Microsoft.Data.SqlClient Azure SQL Database Connectivity Architecture sys.event_log for Azure SQL Database sys.database_connection_stats for Azure SQL Database
Where Does My Microsoft Entra ID Data Reside? Understanding Azure Regions and Data Residency
Hello everyone! Zoheb Shaikh here again. I’m a Senior Cloud Solution Architect with Microsoft, based in Doha, Qatar. It’s been almost three years since my last blog, and I’m happy to be back sharing another interesting customer conversation. This time, we’ll explore what the new Saudi Azure region really means for Microsoft Entra ID and data residency. I was recently having a conversation with a customer about Microsoft’s announcement of the Saudi Arabia East Azure region, which is expected to become available in November 2026. Naturally, there was a lot of excitement around it. We started discussing what this means for workloads, applications, data, resiliency and, of course, data residency. And then came a very simple question. “Great. So once the Saudi Azure region is available, our Microsoft Entra ID will also be in Saudi, right?” It is actually a very good question. And I think this is something we are going to hear more often as local Azure regions become available across different countries. My answer was: “Not exactly. Azure region availability and Microsoft Entra ID data residency are two different things.” And that started an interesting conversation. “But Entra runs on Azure, right?” Yes, But this is where we need to understand the difference between a workload that we deploy into Azure and a cloud service that Microsoft operates for us. Think about a normal Azure workload, you want to deploy a VM > Azure asks you: Where do you want to deploy it? Saudi Arabia East, UAE North, UK South, West Europe. You select the region based on your requirements. The same concept applies to many other supported Azure services. With the new Saudi Arabia East region, customers will be able to access supported Microsoft cloud and AI services and host eligible workloads and data locally in the Kingdom. Microsoft has announced that the region will also include three Availability Zones. That is the Azure region conversation But Microsoft Entra ID is different. You don’t create your Microsoft Entra tenant and then say: “Deploy my Entra tenant into Saudi Arabia East.” That is not how the service is designed. So how does Microsoft Entra actually work? This is where the architecture becomes interesting. Microsoft Entra ID is designed as a geographically distributed identity service. When an Entra tenant is created in the public cloud, the country or region selected during tenant creation is mapped by Microsoft Entra to a geo-location and a scale unit. Microsoft’s documentation currently lists geo-locations such as EMEA, North America, Asia/Pacific, Japan, Australia and Worldwide. The tenant location isn’t simply determined by where you later deploy your Azure VMs or applications. I explained it to the customer like this. If you deploy an application into Azure, you are largely deciding: “Where should my workload run?” For Microsoft Entra, Microsoft is managing a global identity platform and deciding: “How do we keep identity available, resilient and responsive while respecting the service’s data-residency architecture?” They are two very different design problems. Then the customer asked the next obvious question “Why does Entra need to work this way?” And this is probably my favourite part of the discussion. Imagine your company’s entire authentication service was dependent on one datacenter. Your users are signing in, Your applications are authenticating, Microsoft 365 depends on identity, Azure depends on identity. Thousands of applications may depend on the same identity platform and now imagine that datacenter has a problem. Identity is one of those services where availability really matters, this is one of reasons Microsoft Entra uses a distributed architecture. Microsoft’s published architecture describes a directory partition as having a primary replica and multiple secondary replicas. The primary replica handles writes, Before a write is acknowledged as successful, Microsoft Entra replicates that write to a secondary replica in another datacenter. Reads work differently, Directory reads, including authentication requests, can be serviced by secondary replicas that are geographically distributed. Microsoft routes these requests so that they can be serviced from datacenters close to customers. Now the architecture starts making more sense. It isn’t distributed randomly, It is distributed because the identity platform needs to provide things such as: availability, resiliency, performance and data durability. “So when I authenticate, am I always talking to where my directory data is stored?” Not necessarily in the way we traditionally think about it. This was another useful part of our conversation. Microsoft documents the Microsoft Entra authentication service itself as stateless. The directory data required for authentication resides in the Microsoft Entra Core Store. When users authenticate, Microsoft can route them to an authentication service instance in the geographically nearest datacenter that forms part of the applicable Microsoft Entra logical region. This is an important concept. The place from which a service responds to you and the place where the underlying authoritative data is managed do not always have to be the same thing. That is quite normal in large cloud services. And then came the real question: “Where is my data?” This is where I normally slow the conversation down a little. Because there are actually a few different questions hiding inside that one question. The customer might be asking: Where does my application data reside? Or Where does my Microsoft Entra directory data reside? Or Where is my authentication request being processed? Or perhaps the actual concern is Do I meet a specific regulatory requirement? These questions sound similar. But technically, they are not the same. For Microsoft Entra ID, Microsoft’s public documentation says the country/region selected during tenant creation is mapped to a Microsoft Entra geo-location and a scale unit. Microsoft Entra Core Store data is then managed according to that geo-location, considering areas such as performance, usability, residency and other requirements. That is why simply saying: “I have an Azure datacenter in my country, therefore every Microsoft cloud service must now store its data there” would be an oversimplification. There is actually an interesting Saudi-specific detail here At this point the conversation usually gets a little more interesting. Microsoft’s public documentation explains that Microsoft Entra directory location is determined when the tenant is originally created. Changing the country code later doesn’t move the directory data location. There is also some historical behaviour worth understanding. Microsoft documents that several country codes — including Saudi Arabia, UAE, Qatar, Bahrain, Kuwait and Oman — were mapped to the Asia region until 2013 and later mapped to Europe. As a result, tenants from those countries created before July 2013 can be provisioned differently from tenants created afterward. Why do I like this example? Because it makes one thing very clear: You shouldn’t determine your Microsoft Entra data location simply by looking at where your Azure workloads are deployed today but tenant provisioning history matters as well. “Okay, but is distributed data less secure?” This is another place where two conversations sometimes get mixed together. Data residency and security are related, but they are not the same thing. Data residency generally talks about where data is geographically stored. Security talks about how that data and the service around it are protected. Microsoft documents several protections around the Entra service. For example, Microsoft Entra directory data is signed and encrypted while it is being transferred between datacenters within a scale unit, and customer-facing web services use TLS. Microsoft also documents tenant-isolation controls around the Entra Core Store. Microsoft Entra also uses geographically distributed replicas, automated routing, monitoring and failover as part of its service architecture. So I wouldn’t look at a distributed architecture and conclude: “The data isn’t sitting in my local Azure region, therefore it is less secure.” That isn’t the right comparison. But I also wouldn’t say: “The service is secure, therefore data residency doesn’t matter.” That isn’t correct either. Security and regulatory residency are two different conversations This is probably the most important takeaway from the whole discussion. Imagine a customer tells me: “Our concern is security.” Then we should discuss the security architecture, tenant isolation, encryption, authentication controls, privileged access, service resilience and the controls Microsoft has put around the service. But imagine the customer says: “Our regulator specifically requires this category of data to be stored within Saudi Arabia.” That becomes a data-residency and compliance conversation. The right thing to do in that situation is not to make an assumption based on the availability of a local Azure region. Instead, check the official Microsoft documentation for the specific service and the specific data type involved. Microsoft’s Trust Center provides service-specific information for Microsoft Azure, Microsoft 365, Microsoft Entra ID, Intune, Defender and other cloud services. This is important because not every Microsoft cloud service follows exactly the same data-storage architecture. Back to the Saudi Azure region, So after all of this, we came back to where our conversation started. What does Saudi Arabia East actually change? A lot. Microsoft has announced that Saudi Arabia East will allow government and private-sector organizations to access supported Microsoft cloud and AI services and host eligible workloads and data locally in the Kingdom. The region will contain three Availability Zones, providing another important building block for organizations designing resilient local architectures. For customers running Azure applications, data platforms, infrastructure and AI workloads, this is a very significant development. But does that automatically mean an existing Microsoft Entra tenant moves into the Saudi Arabia East Azure region? No, And that shouldn’t really be surprising once we understand how Microsoft Entra is designed. The easiest way I explain it By the end of the conversation, I normally reduce everything into two simple questions. Azure Region is “Where do I want to deploy my workload?” For eligible Azure services, Saudi Arabia East gives customers another local option. Microsoft Entra ID “How does Microsoft’s identity service manage and protect my directory data?” That involves Microsoft Entra geo-locations, scale units, replicas and a geographically distributed service architecture. And then there is a third question which is equally important: Data residency “What does Microsoft commit to regarding the storage of my specific data for this specific cloud service?” That answer should always come from the relevant service documentation rather than from assumptions about where the nearest Azure datacenter happens to be. One last thought I actually think conversations like this are healthy. When customers ask “Where is my data?”, we shouldn’t try to answer the question with one sentence. Because modern cloud architecture doesn’t always work like the datacenter architecture we grew up with. An Azure region. A Microsoft Entra geography. A scale unit. A service endpoint. A replica. A data-residency commitment. They can all be part of the same cloud architecture, but they don’t necessarily mean the same thing. The Saudi Arabia East region is a major step forward for customers wanting to run Azure workloads locally in the Kingdom. And at the same time, it gives us a great opportunity to have a deeper conversation about how global cloud services such as Microsoft Entra ID are actually built. My conversation with the customer started with: “So Entra will now also be in Saudi, right?” By the end, the question had changed to something much better: “What is our actual data-residency requirement, and how does Microsoft Entra meet it?” And I think that is the right conversation to have. References Microsoft announces Saudi Arabia East datacenter region https://news.microsoft.com/source/emea/2026/08/microsoft-announces-saudi-arabia-east-datacenter-region-will-be-available-in-november-2026/ Microsoft Entra ID and data residency https://learn.microsoft.com/en-us/entra/fundamentals/data-residency Microsoft Entra architecture https://learn.microsoft.com/en-us/entra/architecture/architecture Customer data storage and processing for European customers in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/fundamentals/data-storage-eu Microsoft Entra data protection considerations https://learn.microsoft.com/en-us/entra/fundamentals/data-protection-considerations Microsoft Trust Center – Data location https://www.microsoft.com/en-us/trust-center/privacy/data-location I hope this blog helped clarify the difference between Azure regions and Microsoft Entra ID data residency. These are the kinds of interesting customer conversations that I enjoy sharing, and I hope to continue writing more regularly. As always, feel free to share your thoughts, questions or experiences in the comments. I'd love to hear your views! Thanks for reading, and until next time! Zoheb Shaikh Senior Cloud Solution Architect | Microsoft Doha, QatarUpskilling for Technical Architect Design in Azure
I have a strong technical background and am interested in gaining hands-on experience with technical architect design. Could you please advise on the best ways to acquire these skills? I researched alternatives to ERP (Enterprise resource planning) on Google and found the list below of Azure components. Could you please also help to confirm whether I selected the appropriate data from Azure components? Enterprise resource planning Azure Service Finance Microsoft Cost Management Microsoft Dynamics 365 Finance Microsoft Power BI Azure Collaboration Services (Teams, sharepoint to improve collaboration and communication Purchasing Microsoft Dynamics 365 Business Central Power Automate Azure logic Apps custom development Manufacturing Teams for colloboration Dynamics 365 for Field Service Power BI Inventory Mgmt Azure Integration with Existing Systems: Azure SQL Database, Azure Functions, and Azure App Service CRM & Sales Dynamics 365 Sales HR Microsoft Dynamics 365 HR Azure Marketplace HR Apps Build your own HR solution - Azure SQL database, Azure logic and Power BI eCommerce Teams, Azure Boards, MS project and Power BI Service Project Mgmt Reporting Azure DevOPS I've also developed a basic architectural design for maintaining a centralized database for all key components. Would you be willing to review it for any potential improvements? I'm eager to learn and refine my design based on your feedback.
Cloud Migration for large ETL Application
My organization is just beginning a long-term project to Migrate to Cloud. My department runs a set of applications that use ETL as the primary technology for performing a nightly batch and Java to power a User Interface to the data during work hours. The size of our primary database is > 10 TB, and that size is maintained only by aggressive Archive/Purge cycles. During an average nightly batch, we are shuttling > 1 TB of data between the DB and ETL servers. My question is, would anyone even consider moving just the database/UI for an application like ours to the Azure Cloud? The ETL application we use is not Azure friendly, and our batch code complex enough that converting to another platform could take multiple years. Can Cloud-to-Premise data transfer rates support the kind of large data extracts/writes that a nightly batch like ours requires?
