Quick answer: Choose a location for each workload—not one deployment model for the entire organization. Evaluate public cloud where elasticity and managed services fit. Keep components local when physical dependencies, response-time requirements or disconnected operation demand it. Use a hybrid design when different components have different placement needs, and explicitly design their connections and operating responsibilities. These are starting points for evaluation, not automatic approvals. (learn.microsoft.com)
This checklist is for IT managers, architects and application owners comparing deployment options. Before using it, gather an application inventory, a dependency map, business requirements and operating-cost inputs. You do not need to choose a provider first.
1. Understand what public, private and hybrid actually mean
NIST distinguishes deployment models by how cloud infrastructure is provisioned and used:
| Model | Meaning | Important distinction |
|---|---|---|
| Public cloud | Infrastructure provisioned for use by the general public, hosted at the provider’s premises. | “Public” describes the deployment model, not whether your application must be publicly accessible. |
| Private cloud | Infrastructure reserved for one organization, potentially serving several business units. | It can be operated by the organization, a third party or both, and can exist on or off premises. |
| Hybrid cloud | Distinct cloud infrastructures connected through technology that enables data and application portability. | Under NIST’s definition, merely owning servers and using a cloud service does not establish a hybrid cloud. |
NIST also identifies community cloud, which this checklist does not examine in detail. (nvlpubs.nist.gov)
A server room is not automatically a private cloud. NIST’s cloud model includes on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Traditional hosting may lack those characteristics. (nvlpubs.nist.gov)
In this article, local infrastructure includes conventional on-premises servers and edge systems, whether or not they qualify as private cloud. Microsoft’s architecture guidance uses “hybrid architecture” more broadly for combinations of cloud services and infrastructure in data centers or edge locations. Keep that terminology difference visible in your decision record. (learn.microsoft.com)
2. Separate mandatory constraints from preferences
Start with a worksheet for each workload. Use these columns:
Requirement → evidence → owner → pass/fail check → unresolved question
Distinguish two categories:
- Mandatory constraints: Conditions a candidate design must satisfy.
- Preferences: Benefits worth comparing only after mandatory constraints pass.
For example, “must operate when the external connection fails” is a constraint. “Would benefit from simpler provisioning” is a preference.
Use the following questions to structure the assessment:
| Area | Question to answer | Evidence to collect |
|---|---|---|
| Latency | Which business operations have response-time deadlines? | Application traces and an approved performance requirement |
| Data location | Where may each data category be stored and processed? | Reviewed contractual, policy and legal requirements |
| Dependencies | Which systems must communicate immediately? | Dependency map and application-owner review |
| Connectivity | What must work during a network outage? | Outage behavior and recovery test plan |
| Operations | Who can support the proposed design? | Responsibility matrix and skills assessment |
| Cost | What does the complete architecture cost? | Comparable estimates with documented assumptions |
This is a practical assessment template, not a certification method.
Avoid averaging away a failed constraint with a weighted score. If a candidate cannot meet an approved operating requirement, record it as unsuitable or identify the redesign needed before reconsidering it. Microsoft’s hybrid guidance similarly begins with workload and organizational requirements rather than current hardware location. (learn.microsoft.com)
3. Check latency and legacy dependencies together
Assess the complete business transaction, not just the network connection. An application may perform many database queries or API requests before returning an answer. Microsoft documents how numerous small I/O requests can accumulate overhead and impair responsiveness. (learn.microsoft.com)
For each critical transaction, investigate:
- Where the user, application and data store are located.
- Which calls are sequential and which can run independently.
- Whether a database, file share or authentication service must remain local.
- Whether the software vendor supports the proposed environment.
- Which dependencies can tolerate delayed updates.
Measure representative operations under normal and peak load. Record the slow operations as well as averages. Microsoft’s diagnostic guidance recommends load testing, collecting request-level telemetry and profiling the application to identify I/O bottlenecks. (learn.microsoft.com)
Do not move a web tier independently just because it is easy to deploy. Microsoft’s migration guidance distinguishes direct, low-latency dependencies from occasional interactions and recommends moving directly connected components together. (learn.microsoft.com)
Your placement options might therefore be:
- Keep tightly coupled components together locally.
- Move the coupled group together.
- Redesign the integration before separating components.
Treat “legacy” as a prompt to investigate, not a permanent exemption. Document exactly what prevents movement: hardware access, unsupported software, licensing, protocol behavior or an application change that has not yet been funded.
4. Map data location and control requirements
Create a data-flow diagram before accepting a region or facility as suitable. Identify primary data, replicas, backups, logs, telemetry and administrative data. Microsoft’s guidance explicitly calls for considering different data categories and warns that running locally does not, by itself, satisfy sovereignty, privacy or regulatory requirements. (learn.microsoft.com)
Ask the relevant security, privacy and legal reviewers to resolve:
- Which locations are permitted for storage and processing?
- May replicas and recovery copies use other locations?
- Who may administer the system or access support data?
- Who controls encryption keys?
- What retention and deletion evidence is required?
- Which requirements apply to the complete service rather than its main database?
Record the requirement and supporting evidence, not simply “compliant.”
Separate application data from its management dependencies. A workload can run locally while using a cloud-hosted management control plane; connected and disconnected architectures can have different capabilities. Verify the operating model rather than inferring independence from hardware location. (learn.microsoft.com)
Practical check: Follow one data item through ingestion, processing, logging, backup and recovery. If any location or access path remains unknown, mark the placement decision as provisional.
5. Design connectivity and assign operating ownership
For every proposed boundary between local and cloud components, write down the intended behavior when that connection becomes slow or unavailable.
Your checklist should specify:
- Which operations continue.
- Which operations stop or degrade.
- How users receive an accurate status.
- How queued work is reconciled after reconnection.
- Who investigates failures across the boundary.
Compare connectivity options against the workload’s needs. For example, Azure’s architecture guidance describes site-to-site VPN traffic as encrypted traffic typically carried over the public internet, while ExpressRoute uses dedicated private connectivity. The options have different performance and operating trade-offs; neither name substitutes for an end-to-end test. (learn.microsoft.com)
Then assign responsibility for identity, networking, deployment, monitoring, patching, backup and incident response. Microsoft’s cloud-readiness guidance identifies governance, security, identity, networking, management and workload design as foundational skill areas. (learn.microsoft.com)
Use a simple ownership test: can the named operator explain how to diagnose a failed transaction, restore service and escalate a problem outside their responsibility?
Where the answer is no, add training, external support or a simpler design before approving production placement. Include those costs and responsibilities in the comparison.
6. Compare total cost for equivalent service outcomes
Do not compare a single cloud virtual machine with an entire server purchase. Define equivalent performance, support and recovery requirements, then estimate the complete alternatives.
AWS’s cost guidance recommends including operations and management in total cost of ownership, particularly when comparing managed and self-managed services. (docs.aws.amazon.com)
Use this planning structure:
Total cost = transition costs + infrastructure and service charges + connectivity + operations + protection and recovery + eventual exit
Collect inputs for each candidate:
| Cost category | Inputs to request |
|---|---|
| Transition | Assessment, application changes, migration, testing and temporary duplicate environments |
| Infrastructure/services | Compute, storage, requests, licenses and support |
| Local facilities | Hardware renewal, maintenance, power, cooling and space allocation |
| Connectivity | Circuits, gateways and applicable transfer charges |
| Operations | Staff time, training, monitoring and incident response |
| Recovery | Backup storage, replication, standby capacity and restore testing |
| Exit | Data export, replacement integration and decommissioning |
This is a worksheet, not a price estimate. Use current quotes and provider pricing for the actual services, locations and traffic paths.
Model ordinary, peak and reduced demand rather than assuming one constant load. AWS recommends evaluating transfer costs at different usage levels and identifying traffic sources and destinations. (docs.aws.amazon.com)
Also ask what costs actually disappear after a move. Retained equipment, facilities or contracts should not be counted as immediate savings without evidence that the expense ends.
7. Worked example: factory application and customer portal
The following is a hypothetical decision walkthrough, not a customer case study or measured deployment.
Assume an organization is assessing:
- A factory application that exchanges time-sensitive instructions with local equipment and must continue during external connectivity loss.
- A customer portal with variable demand and a legacy back-office dependency.
These assumptions require validation by the application owners.
Factory application: Begin by evaluating local placement for equipment-facing components. Microsoft identifies physical-system dependencies, latency and operational independence as reasons workloads may need to remain local. (learn.microsoft.com)
Test the proposed design in a safe, representative environment. Verify equipment communication, authentication, restart behavior and the handling of an external outage. Do not assume that a local server guarantees local operation if essential dependencies remain remote.
For optional reporting, evaluate exporting approved data after the operational transaction. Decide separately whether delayed reporting is acceptable and which data may leave the site.
Customer portal: Evaluate a public-cloud design alongside local alternatives. First trace its back-office interactions. If each page requires immediate remote database access, assess moving the coupled components together or changing the integration before separating them. That follows Microsoft’s dependency-grouping guidance. (learn.microsoft.com)
An alternative worth testing is a portal that reads an approved synchronized data set and exchanges background updates. Do not approve it until business owners accept the freshness, reconciliation and failure behavior.
The resulting proposal could be:
| Component | Candidate placement | Approval condition |
|---|---|---|
| Equipment-facing factory application | Local | Performance and disconnected-operation tests pass |
| Factory reporting | Local or cloud | Data flows and reporting delay are approved |
| Customer portal | Public cloud candidate | Dependency, capacity and recovery tests pass |
| Legacy back-office system | Retain initially | Support and integration requirements remain satisfied |
No savings, latency or availability result can be inferred from this table. Those outcomes remain unverified.
8. Avoid common mistakes and record the decision
Before approving placement, check for these shortcuts:
- Calling every server room a private cloud: Use the deployment-model definitions accurately. (nvlpubs.nist.gov)
- Splitting components before mapping dependencies: Review the complete dependency group. (learn.microsoft.com)
- Comparing only compute prices: Include operations and transfer costs. (docs.aws.amazon.com)
- Treating local deployment as proof of compliance: Review the full solution and required controls. (learn.microsoft.com)
Finish with a short decision record:
- Workload and accountable owner.
- Candidate placements considered.
- Mandatory constraints and evidence.
- Chosen component locations and data flows.
- Test results and unresolved questions.
- Cost assumptions and operating responsibilities.
- Rollback approach and review triggers.
Before migration, define rollback criteria and procedures; Microsoft’s migration guidance explicitly calls for doing so before deployment begins. (learn.microsoft.com)
Schedule reassessment when requirements, dependencies, support arrangements or costs change. The goal is not to select a permanent organizational label. It is to make each placement decision explainable, testable and supportable.