Can This Workload Move to AWS Before Its Renewal?

Test renewal feasibility with separate notice and source-exit deadlines, a backward dependency schedule, recovery reserve and explicit unknown-input holds.

A workload can fit before a source-service exit date and still miss the renewal decision. The contract might require notice before the team can produce the evidence needed to authorize that notice. Calculate both paths before promising a migration date.

Start with two independently confirmed anchors: when valid notice must be received, and when the source service must be safely releasable. Work backward through their prerequisites. Where two activities can run concurrently, use the longer path. Where one depends on the other, add their durations. Keep acceptance and recovery capacity in the schedule. A required duration marked UNKNOWN blocks a supported feasibility answer.

This article helps an engineering sponsor and procurement owner decide whether one bounded migration merits further commitment before a renewal. It supplies a fictional elapsed-day calculation and a reusable evidence record. It does not interpret a contract, authorize termination or establish a delivery promise. No AWS migration, contractual notice or customer test was executed. All durations and deadline offsets below are invented teaching inputs, not service estimates.

Confirm what the deadline requires

Ask procurement to identify the governing agreement, exact service scope, notice mechanism, recipient, effective date and evidence of receipt. Record the actual timestamp and timezone. An internal reminder or a salesperson's renewal estimate does not establish these terms. Neither does an AWS document about migration tooling.

Use separate fields for the notice boundary and source-exit boundary. A contract might allow notice before migration acceptance, might require a decision weeks earlier, or might have no relevant cancellation right. The organization may also set a stricter internal rule: no notice until a representative rehearsal and readiness review pass. That internal rule becomes a dependency in the model; it must not be attributed to the supplier.

Notice received

Evidence needed: Governing terms, authorized scope, receipt channel and timestamp

What it does not establish: Successful migration or a right to withdraw notice

Source exit complete

Evidence needed: Defined workload acceptance, recovery custody and release obligations

What it does not establish: Automatic end of every source payment

Cutover window

Evidence needed: Application owner approval, permitted interruption and operational coverage

What it does not establish: Contract termination or safe source deletion

A source contract ending and an application moving traffic are different events. Include export, retention or release work before the exit boundary when the actual obligation requires it. Do not put deletion on the critical path unless the authorized retention decision requires deletion by that boundary. Keeping a protected recovery artifact might remain necessary after source service ends.

If the notice date has passed, preserve that fact. Ask procurement what options remain under the agreement. A short extension, amended scope, renewed service or later move can be considered only when available and authorized. The schedule must not silently roll the date forward or assume a waiver.

Build dependencies before estimating the finish

List evidence-producing activities, their owners, prerequisites and elapsed durations. “Migration takes six weeks” conceals whether target preparation can begin before procurement, whether a specialist is available, and whether the rehearsal represents the actual application.

AWS recommends a cutover plan that includes task durations, sequence, owners, testing and failure contingencies. Its pre-cutover guidance includes rollback time and fix-forward contingency in the downtime assessment. Those are planning requirements to investigate, not vendor-supplied durations for this workload.

Use a directed acyclic graph: each task names the tasks that must finish before it starts. A rehearsal can depend on both procurement completion and a prepared target. Neither branch alone permits it to begin. If the same engineer must perform both branches, add the resource constraint as a sequence or use a resource-aware planning tool. Drawing parallel lines does not create parallel capacity.

AWS's wave-planning guidance includes technical dependencies, resource availability, maintenance windows and business dates. It provides no predefined duration applicable to every migration. For this decision, treat those constraints as inputs to the particular dependency group rather than borrowing a generic wave length.

For each duration, retain the evidence boundary. A representative rehearsal might support the application handover portion, while a procurement owner supplies a separate approval lead time. A previous small data copy cannot establish the duration of an untested larger transfer. Mark unsupported required work UNKNOWN until the owner supplies a defensible bound or a scoped experiment.

Worked case: exit fits, notice does not

The example uses integer elapsed days from an arbitrary day 0. There are no dates, weekends, holidays or timezones in the arithmetic. Durations include any stipulated waiting time. Real workday calendars and approved execution windows would require a different model before converting these offsets into dates.

Assume, solely for this fictional case, that procurement has confirmed notice must complete by day 30 and source exit by day 90. The organization requires a successful rehearsal and readiness review before authorizing notice. Notice processing takes another two elapsed days. Procurement and target preparation can run concurrently after discovery because separate capacity is stipulated. Both must finish before the rehearsal.

Discovery and dependency confirmation

Duration, days: 10

Must follow: Start

Earliest start to finish: 0 to 10

Procurement and access approval

Duration, days: 18

Must follow: Discovery

Earliest start to finish: 10 to 28

Target preparation

Duration, days: 14

Must follow: Discovery

Earliest start to finish: 10 to 24

Representative replication and rehearsal

Duration, days: 20

Must follow: Procurement and target

Earliest start to finish: 28 to 48

Readiness evidence and decision

Duration, days: 4

Must follow: Rehearsal

Earliest start to finish: 48 to 52

Authorized notice processing

Duration, days: 2

Must follow: Readiness

Earliest start to finish: 52 to 54

Cutover attempt

Duration, days: 2

Must follow: Readiness

Earliest start to finish: 52 to 54

Business acceptance and handover

Duration, days: 7

Must follow: Cutover

Earliest start to finish: 54 to 61

Protected recovery reserve

Duration, days: 5

Must follow: Acceptance

Earliest start to finish: 61 to 66

Source-exit administration

Duration, days: 3

Must follow: Reserve

Earliest start to finish: 66 to 69

The five-day reserve is a protected planning allowance before source release, not an assertion that recovery takes five days or succeeds within it. The application owner must define which supported recovery or remediation path it covers, what starts its clock and what evidence would justify its size. This conservative scenario holds the allowance after acceptance instead of treating it as free capacity for feature work.

Procurement controls the parallel join: max(18, 14) = 18 days. Readiness completes after 10 + 18 + 20 + 4 = 52 days. Notice completes on day 52 + 2 = 54, missing its day-30 boundary by 24 days. Source exit completes on day 52 + 2 + 7 + 5 + 3 = 69, leaving 21 days before day 90.

Adding every task would be wrong. It would count procurement and target preparation sequentially, and would also count notice as if it delayed cutover. The modeled branches share readiness but have different sinks. Conversely, deleting procurement because it sounds administrative would omit a prerequisite the case explicitly requires.

The outcome is DOES NOT FIT under the stated policy. “We have 90 days and need 69” answers only the source-exit question. Sending notice on day 30 would cross the organization's evidence gate before readiness on day 52. Changing that policy needs its own accountable decision about exposure; the calculation cannot authorize it.

*In this fictional elapsed-day plan, notice and cutover share readiness but have different deadlines. Procurement and target preparation run concurrently, so their join uses max(18,14), not their sum. A positive recovery allowance precedes source exit. Arrows show modeled prerequisites, not traffic or an executed migration. The task table above supplies the full text equivalent.*

Work backward from both sinks

For the source-exit path alone, the latest start is 90 - 69 = day 21. For the notice path, it is 30 - 54 = day -24. Both must hold, so the last permissible common start is the earlier value, day -24. At day 0 that modeled opportunity is already 24 days behind schedule, even though the notice deadline itself has not yet elapsed.

The backward pass exposes intermediate gates as well. Notice processing must start by day 28. Readiness must therefore finish by day 28 and start by day 24. The rehearsal must finish by day 24 and start by day 4. Procurement must start by day -14, with discovery starting by day -24. Target preparation can start by day -10 because its branch is four days shorter.

These latest times are constraint bounds, not an execution order. The exit-only branch has additional waiting room because its boundary is later. Keeping cutover at its earliest modeled day 52 does not make notice feasible. Waiting until the exit branch's latest cutover day 73 would also require operational readiness and estimates to remain valid, which this arithmetic does not prove.

In a second fictional case, change only the notice boundary to day 60. The notice path permits a start on day 60 - 54 = 6; the exit path still permits day 21. The combined latest start becomes day 6. Starting on day 6 meets notice exactly on day 60 and exit on day 75. Starting on day 7 misses notice by one day, although exit still completes by day 76.

“Fits the model” is the strongest permitted result. Zero margin at a boundary leaves no unmodeled delay allowance. It does not establish that a supplier will accept notice, a rehearsal will pass, or a production migration will finish at the calculated time.

Challenge the parallelism and reserve

Suppose target preparation requires the newly approved access produced by procurement. Replace their parallel relationship with procurement followed by target preparation. Readiness now takes 10 + 18 + 14 + 20 + 4 = 66 days. Notice finishes on day 68; source exit on day 83. Against the original deadlines, the latest common start becomes day 30 - 68 = -38. The dependency adds 14 days, not four.

That counterexample is why a shorter branch cannot automatically be treated as usable slack. Ask what must be available at its start: account access, connectivity, licensing, an approved architecture, a test dataset and the people needed to prepare it. Where an input is missing, either model the prerequisite or explain why the work can proceed without it.

Do not create a fit by removing acceptance or reducing recovery reserve to zero. The fixture deliberately returns HOLD when the required reserve is absent or zero. That is this planning policy's gate, not an AWS requirement for a universal number of days. A justified different allowance can be modeled separately with the application owner's evidence and approval.

Recovery capacity also changes after target writes. Returning traffic to an old database can lose new acknowledged work if no reconciliation path exists. Use the database cutover and rollback article for that operational boundary. The day-scale reserve here funds time to use the selected recovery design; it does not supply the design or turn a stale source into a safe fallback.

Post-cutover acceptance should cover the business behavior being moved. AWS's post-cutover guidance recommends workload-appropriate monitoring and a support period, noting that a quarterly batch may need more observation than a short warranty window. If a required business cycle cannot be observed before the source-exit boundary, record the missing evidence and the owner's available alternatives. A green health endpoint cannot replace that acceptance.

Handle unknowns and elapsed dates without a false answer

Use explicit decision states so a calculator cannot convert missing data into optimism.

HOLD

Condition in this bounded model: Required contract input, duration, dependency or positive reserve is missing or invalid

Next action: Assign an input owner; obtain evidence before calculating feasibility

DEADLINE ELAPSED

Condition in this bounded model: A confirmed required boundary is already earlier than the evaluation time

Next action: Procurement establishes remaining options; preserve the elapsed boundary

DOES NOT FIT

Condition in this bounded model: At least one modeled earliest finish exceeds its deadline

Next action: Change evidenced scope, dependencies or available terms, then compare a new version

FITS MODEL ONLY

Condition in this bounded model: Every required modeled sink meets its deadline

Next action: Review capacity, timing uncertainty and execution gates before any commitment

The offline fixture checks input validity before returning numerical feasibility. For example, an unknown procurement duration returns HOLD with no calculated latest start. An elapsed notice boundary can still be recorded as a known issue in the evidence record; other unknowns do not make it disappear. There is no probability of success in this model.

When the outcome fails, compare supported alternatives. A smaller independently releasable workload could shorten the dependency chain, but only if shared interfaces and source charges permit separation. A confirmed short extension could change the contract anchor. Staying through the renewal and moving later could preserve service at additional cost. None of those alternatives is automatically available or financially preferable.

Use the migration overlap budget to price a changed overlap period and commitment reconciliation to determine which obligations survive the move. This schedule answers whether the required evidence can arrive in time; those articles answer different cash questions.

Fill the decision record before discussing dates

Keep the contract evidence access-controlled. The public example contains no real agreement, supplier negotiation, account plan or funding formula. A team can share a redacted decision record without publishing private terms or credentials.

Bounded workload and owners

Filled fictional record: One application dependency group; engineering sponsor, application owner and procurement roles only

Evaluation and units

Filled fictional record: Day 0; integer elapsed days; no workday conversion

Notice evidence

Filled fictional record: Stipulated receipt deadline day 30; readiness required by internal policy; two days processing

Source-exit evidence

Filled fictional record: Stipulated safe release deadline day 90; acceptance, recovery allowance and administration included

Parallelism

Filled fictional record: Procurement 18 and target 14 after discovery; separate capacity stipulated

Readiness output

Filled fictional record: Representative rehearsal 20 days, then evidence review 4 days; no actual results claimed

Earliest required outcomes

Filled fictional record: Notice day 54; cutover day 54; accepted day 61; exit day 69

Margins and last start

Filled fictional record: Notice -24 days; exit +21 days; common latest start day -24

Decision and authority

Filled fictional record: DOES NOT FIT; no notice, deletion or migration authorization supplied by this record

Open action

Filled fictional record: Procurement evaluates available terms; engineering challenges scope and dependencies before a new version

Copy the following blank record for a real review. UNKNOWN is an acceptable saved state, but not a valid duration in a feasibility total.

Scope and version

Required record: Workload/dependency group, inventory version, exclusions and evaluation timestamp

Contract anchors

Required record: Governing instrument reference, notice receipt timestamp/timezone, release scope, confirming owner and evidence

Evidence policy

Required record: Required evidence before notice, signatory authority and any independent source-exit gate

Task rows

Required record: ID, named owner, prerequisite IDs, elapsed duration, evidence reference/date and uncertainty

Capacity and windows

Required record: Shared resources, approved execution windows, waiting time and calendar conversion method

Acceptance and recovery

Required record: Required business checks, observation period, supported recovery path and protected allowance

Results

Required record: Earliest finish per sink, margin, latest start and binding dependency path

Missing evidence

Required record: UNKNOWN inputs, accountable owner, next check and decision held

Authorized next action

Required record: Stay, seek terms, narrow scope or continue planning; approval reference separate from model result

Preserve each version rather than overwriting a failed plan. If the notice date changes, retain the evidence that changed it. If a rehearsal finds a missing writer or a slower data path, update the dependency and duration rather than leaving the old “feasible” result in the approval pack.

Reproduce the arithmetic, then review the real constraints

Download the offline renewal-feasibility source package (ZIP)

The companion source package contains a pure offline dependency calculator, fictional JSON inputs and boundary tests. It computes earliest start as the maximum predecessor finish, then computes latest finish as the minimum of downstream latest starts and any deadline on that task. It rejects cycles, missing predecessors, unbounded branches and invalid or unknown durations. The tests check every forward and backward row independently against hand-worked expected values.

Its scope is deliberately small: integer elapsed days, finish-to-start dependencies, unlimited parallel capacity unless explicitly sequenced, and a required positive recovery allowance. It does not model working calendars, probabilistic delays, staffing optimization, vendor lead-time promises or legal eligibility. It makes no network requests and cannot send notice, purchase anything or change AWS resources. A future interface would need to expose those limits beside its result rather than label it a promised completion date.

The companion explicitly identifies the source-exit task and requires the positive reserve to be its transitive prerequisite. A separately bounded reserve branch that exit can bypass returns HOLD. Derived margins are also checked for safe-integer arithmetic; a number that exceeds the supported range cannot establish feasibility.

Take the two deadline anchors and the longest prerequisite path to the next review. Ask procurement to confirm the notice evidence and engineering to demonstrate the rehearsal and recovery assumptions. Until those inputs are supportable, keep the decision on HOLD rather than placing an unsupported migration date in a renewal negotiation.