What the cloud is genuinely bad at
The migration meeting starts with a cheerful slide: move all forty stores to Azure. Then the store manager asks a smaller question. “Will tonight’s till upload still finish before we open?” That batch job talks to a local device and carries a licence restriction. Before you move it, you need its transfer volume, measured round-trip time and licence terms. A mechanic checks the troublesome engine before recommending a new car. You owe this workload the same care.
Classes One and Two introduced the cloud and an illustrative business case. This class asks where those assumptions stop working. A workload can benefit from managed services and still need a local component, a different data path, or a later migration date.
Moving an application changes its operating environment; it does not automatically repair its design. Rehosting with minimal changes can be a sensible way to leave a datacentre or meet a deadline. Set the goal explicitly, test compatibility and cost, and decide whether further redesign is justified.1
- Data gravity
- The tendency of a large dataset to pull applications and services toward wherever it already lives, because moving the data is slower and costlier than moving the code that uses it.
Data gravity is a useful design lens. Before moving a web tier, map the databases, archives and integrations it calls. A new network boundary can introduce transfer charges, delay and another dependency even when the application itself moves easily.
In our fictional Campux Retail case, the web tier moves to Azure while the order database stays in the office. Each request now crosses that connection. Draw the traffic on the architecture diagram, estimate its volume, and test the response time and failure behavior. Moving the easy component first is progress only if the resulting system still meets its requirements.
Egress: paying for data that leaves
Ingress means data entering an environment; egress means data leaving it. Uploading a file from your laptop to Azure is ingress to Azure. Downloading it from Azure to your laptop over the internet is egress from Azure. GB (gigabytes) measures the amount transferred. A bandwidth charge is one part of the bill, separate from storing or processing that file.
Azure lists inbound bandwidth at no charge. That is a statement about the bandwidth meter, not free ingestion or unlimited capacity: storage, operations, processing and network services can still cost money, and service limits still apply. Internet egress often has a per-GB charge after an allowance; the actual price depends on the source region, route and service.
- Egress
- Data transferred out of a service or network boundary. Trace the source, destination, route and service before deciding which transfer meter applies.
For this worked example, use the published North America / Europe internet-egress rates through Microsoft Premium Global Network, in USD, checked on 1 October 2026.2 Use decimal units: 1 TB = 1,000 GB. These are marginal tiers, not one rate applied to the entire month. Other regions, routes, services and agreements can differ; this example excludes all other charges.
| Direction / volume | Charge |
|---|---|
| Inbound bandwidth | No bandwidth fee |
| Outbound, first 100 GB per month | Free |
| Outbound, next 10 TB after the allowance | $0.087 per GB |
| Outbound, next 40 TB | $0.083 per GB |
| Outbound, next 100 TB | $0.07 per GB |
| Outbound, next 350 TB | $0.05 per GB |
No inbound bandwidth fee does not mean free ingestion.
Suppose the fictional finance team downloads 5 TB each night for 30 nights. That is 150,000 GB. After the 100 GB allowance, the example charge is 10,000 × $0.087 + 40,000 × $0.083 + 99,900 × $0.07 = $11,183 for the month. Twelve identical months would be $134,196. These are bandwidth estimates, not an invoice: storage, requests, processing, connectivity, tax and any negotiated terms are separate.
Compare moving the reporting compute nearer the data, reducing the extract, or aggregating before transfer. Each changes more than the bill: check access controls, freshness, recovery and operating effort. The useful review question is what crosses the boundary, how often, and in which direction?
What would your nightly extract cost?
Use the example tiers above, a 100 GB monthly allowance and no other internet egress. Enter GB transferred each night and nights in one month. This estimates bandwidth only.
100 GB free + 10,000 GB × $0.087 + 40,000 GB × $0.083 + 99,900 GB × $0.07. Other charges are separate.
Latency: how long a response takes
Latency is a delay. If your application sends a request and waits for the reply, the time until that reply returns is its round-trip response time. A millisecond (ms) is one thousandth of a second. We care about this delay separately from how much data a connection can carry.
Distance adds a physical floor to network delay, and actual requests also encounter routing, switches, queues and processing. A service-level agreement does not remove that delay. Compare the application's response-time requirement with measured end-to-end performance on the proposed path.
A storefront and an industrial control loop need different measurements. For the storefront, test page response and tail latency under load. For a local machine with a strict response deadline, test that deadline and the behavior when connectivity fails. Keep the time-critical part at the edge or on-premises if the proposed remote path cannot meet it; reporting and analytics may still run in the cloud.
The fictional stores need a documented plan for losing the connection to Azure. Decide which operations can continue locally, what must stop safely, and how queued work is reconciled when connectivity returns. A local component is a design decision, not a reason to place every system in the same location.
For example, assume a machine requires a 1 ms round trip and tests show the proposed regional path cannot meet it. Retain the local control loop while evaluating other components separately. Ten sequential calls can also accumulate delay; batching or caching may help, but measure the result. Azure's published region-to-region latency statistics provide context, not a promise for your office-to-application path. Record the median, p95/p99, test conditions and failure behavior.
Compliance, residency and custody
Some workloads have storage, processing, access or licensing requirements that constrain their placement. Ask the responsible legal, security and business teams to state those requirements before choosing a service. Translate them into a design you can verify; do not infer compliance from a region name alone.
- Data residency
- A requirement that data be stored, and sometimes processed, within a defined geography — a country or economic region — to satisfy a law, a regulator, or a contract.
Azure offers regional and nonregional services, with different residency commitments and configuration choices. Check the selected service, geography, processing path, backups, replication, logs and support arrangements against the approved requirement. Customers select and configure an appropriate solution; Microsoft is responsible for its stated service commitments. An in-country region may satisfy a requirement, but its existence does not establish that your whole system does. Read the Azure regions overview and the specific service documentation.
Money, response time and requirements are three useful checks, not an exhaustive list or a ranking of how often problems occur. Compatibility, security, reliability, team capacity and migration risk can also decide whether a proposal is ready.
Portability and operating skills
Include portability and operating skills in the initial business case. They can matter immediately as well as later.
Vendor lock-in means changing providers may require changing application code, integrations or operating procedures. Managed services can save work, so weigh that benefit against the effort to replace them. Test an export or recovery path for important data. Microsoft offers egress credits for eligible exits through a documented support process; ongoing hybrid transfers are a different case. An exit credit does not remove rewriting, testing, staffing or other service costs.
Operating skills belong in the budget. An experienced infrastructure team brings useful knowledge, but still needs service-specific training, access controls, monitoring, incident response and ownership. Provider tooling can detect or prevent some misconfigurations; it does not remove the customer's responsibilities. Review the shared-responsibility model for the services you plan to use.
Play it through
Three minutes with a fictional migration list. The storefront has a tested scaling plan and an acceptable cost estimate. The sensor misses its latency target on the proposed regional path; the batch job has an unresolved machine-bound licence. Sort these proposals, then explain what could change each decision.
When workloads move back
Repatriation means moving a workload from the cloud back to owned or hosted infrastructure. It is one option when requirements or economics change, alongside resizing, using commitment discounts where appropriate, or changing the application. Start from the future costs and risks of each option, including the cost of changing course.
Steady demand makes it easier to compare capacity options, but does not prove that owned hardware is cheaper. Include facilities, power, hardware replacement, licences, people, support, security and recovery, as well as cloud charges and managed-service benefits. Retaining an existing system can be reasonable when it meets the business need and migration has low expected return.3
The Phase One recap contains a separate illustrative cost exercise. Treat its assumptions as inputs to question, not proof of your own decision. Figure 2 is an initial review checklist; resolving its four questions does not replace a complete assessment.
The one system you do not migrate yet
In this fictional case, leadership wants every system in Azure by year-end. The overnight POS reconciliation job has a third-party licence explicitly tied to its current physical machine. Assume the proposed cloud VM is not permitted under that contract until an agreement is reached. The job's age and steady schedule are background facts, not proof of cost savings or impossibility.
Recommend retaining the job for now. Assign an owner and review date for the licensing question, document the current server's support and recovery risks, and compare the total cost of the permitted options. If a hybrid connection is needed, price and secure it too. Revisit the decision when the contract and business case are ready.
A useful recommendation gives leadership a constraint, evidence, a next action and a date to reconsider. That is a plan the team can act on.
Zoom out: the decision to move is one the rest of the system inherits
You can now argue both sides of the cloud. Now reason about the second-order life of the choice, because "should this move" is rarely answered by the workload alone.
A migration that preserves an inefficient design may preserve its costs too. Measure before and after the move, set a budget alert, and make optimization an explicit task instead of assuming it will happen.
Moving one system rarely moves it alone — it drags its integrations, its data gravity, and its latency to the things it talks to. Map what a workload is coupled to before you decide it can leave.
Find the constraint that matters for this proposal: it might be a data dependency, an unmet requirement, licensing, compatibility, cost or team capacity. State what evidence would let you revisit it.
A retained system still needs identity, monitoring, recovery and a secure connection to its dependencies. Include that ongoing work when comparing a hybrid design with other options.
A reason-not-to that is a rounding error for one app — a little egress, a small latency — becomes the architecture's defining cost once fifty apps share it.
The engineer who ships is asked "can it move?" The engineer who gets promoted is asked "and what moves with it?" — and has already followed the couplings out.
The person who says "not this, not yet"
An eager lead proposes lifting a latency-critical box and a decade-old licensed appliance straight to Azure. You are the one who says "not this, not yet." You separate what the cloud makes better from what it makes worse or merely more expensive, and hand back the migration list with two items crossed off and a reason beside each. Knowing when not to is the judgment that gets you trusted with the yes.
Price the transfer before the move
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Nightly export: 40 stores × 2 GB 30-day example: 30 exports per store Illustrative transfer rate: $0.08 per GB
Calculate the monthly volume before applying any rate.
Use the supplied rate to calculate this one transfer component. Record that it is an invented rate, not an Azure quote.
List the actual direction, service, region, free allowances and licence terms you must check before proposing the move.
On your own: the shop grows to 55 stores and compression cuts each export to 1.5 GB. Work out the new monthly volume and the transfer cost at the same rate before opening the reveal.
Check your reasoning after you finish
On your own: 55 × 1.5 × 30 = 2,475 GB, about $198 at $0.08/GB. More stores almost cancelled the compression, which is why you recalculate instead of guessing. 40 × 2 × 30 = 2,400 GB. At the supplied $0.08/GB, that component is $192. This excludes compute, storage and other transfer paths. Compare the same measured workload and contract terms before deciding.
Examination
Four graded drills, then two unscored situations. Try your own reasoning before revealing the model response. Practice can be repeated without changing the first-attempt score; the lesson game can save progress in this browser.
B. Internet egress beyond the example allowance has a bandwidth charge. Inbound bandwidth has no listed fee, but writing data can still incur storage and operation charges. That makes C a different meter, not free storage. Always check the selected route and service rather than applying this example to every transfer.
C. This is a residency requirement. Verify the provider's commitments for every relevant service, then configure and test the customer-controlled parts. Include processing, replication and backups. A region selection alone is not evidence that the complete application meets the requirement.
The cost comparison, measured latency failure and unresolved licence. Each supplies evidence about this proposal. High utilization, age, ownership preference or a competitor's choices are not enough on their own. A different design, agreement or business need could change the recommendation.
MEMORANDUM — Analytics migration plan
1. Use a tested autoscaling configuration for month-end reporting.
2. Budget for Blob Storage capacity, requests and processing.
3. Download 1,000 GB to the on-prem BI tool nightly for 30 nights,
using the internet-egress assumptions in Table 1.
4. Inbound bandwidth is free, so the nightly downloads cost nothing.
Line four. The downloads travel out of Azure, so inbound pricing does not price this path. With the stated assumptions, 30,000 GB minus the allowance gives 10,000 × $0.087 + 19,900 × $0.083 = $2,521.70 in monthly bandwidth charges. Lines one and two describe explicit testing and budgeting, not automatic scaling or free storage.
Put that estimate alongside the separate storage and processing budget. Then compare a smaller extract or moving the reporting step nearer the data. Estimate the complete proposed design before deciding which option is worthwhile.
Ask for the assessment. “Everything, this year” needs workload evidence: inventory, dependencies, requirements, costs, risks and team capacity. Do not infer the presenter's compensation or motives from the proposal.
Use the facts you have. The fictional storefront is a candidate for a pilot under the stated assumptions. The POS licence needs resolution; the control loop needs a path that meets its tested deadline. Avoid promising a direction for the rest of an estate you have not assessed.
Propose a sequence. Assign owners to unresolved questions, test a representative workload, and define acceptance and rollback criteria. Bring the results back to leadership with a phased recommendation and a review date.
State the case assumption. The current licence does not permit the proposed cloud VM. Ask the contract owner to confirm available options before authorizing that move. The age of the server is a reason to assess support risk, not a reason to ignore the contract.
Compare the permitted options. A steady overnight job is not automatically cheaper on-premises. Include migration effort, operating cost, support and recovery in the comparison. Keeping an ageing server indefinitely also has risks.
Give a route forward. Assign a licensing owner and a review date, maintain support and backups while the job is retained, and evaluate the secured connection it needs during the wider migration. Reconsider once the contract, performance tests and cost comparison are ready.
Five things worth carrying out of this class
- Rehosting can meet a business goal; redesign is a separate decision. State the goal and test the result.
- Price the data path and every relevant meter. No inbound bandwidth fee does not make storage or processing free.
- Measure end-to-end response time under load. Keep the time-critical component near what it controls when the remote path cannot meet its target.
- Residency requires service-specific commitments and an appropriate configuration, checked against the approved requirement.
- Recommend retain, revise or migrate with evidence, an owner, acceptance criteria and a date to reconsider.
- Microsoft’s migration-strategy guide describes rehosting and retaining as legitimate choices for different business needs. Minimal application change is not itself a failure. ↩
- Azure bandwidth pricing, checked 1 October 2026, supplies the example rates and decimal units. Check the current region and routing option before budgeting. Blob Storage pricing covers separate capacity and operation charges. The exit-credit process has eligibility conditions and exclusions; it is not a waiver for ongoing hybrid traffic. ↩
- Use a per-workload business case rather than a utilization rule. The migration-strategy guide above includes retaining stable systems that meet business needs when migration has little expected return. Price reliability, operating effort and managed-service benefits as well as compute. ↩
Compare a migration proposal using transfer costs, measured latency, requirements and a per-workload business case.
Play the lesson above to stamp this class.
Next, the one diagram every entry-level interview asks you to draw.
Next · IaaS, PaaS & SaaS →