Database-Led Migration: Choose the Workload Boundary Before the Target

Compare managed SQL Server, retained self-managed hosting and staged relocation using obligation-complete groups, explicit cut edges and whole-scope decision records.

Abstract

Choose the migration boundary around a complete business obligation before choosing where its database runs. A database can be a viable managed-service candidate while the proposed workload move remains incomplete: an exporter still needs the old host, a shared writer cannot move in the same window, or a retained consumer lacks an accepted cross-site contract. Approve a placement only when every required contribution is supported inside the proposed group or crosses a separately owned and evidenced boundary. Evaluate costs only after that feasibility test; a cheaper incomplete scope is not an alternative to a complete one.

This paper compares three choices for SQL Server 2019 Standard on a self-managed Windows host: move the database to standard Amazon RDS SQL Server 2019 Standard and externalize required host work; retain an explicitly supported self-managed group; or relocate a separable application in stages while keeping database and host authority together. Exact source build, Windows version, target RDS minor, Region, account, topology and commercial terms are UNKNOWN. RDS Custom, engine conversion and other SQL Server major versions are excluded. Vendor documentation checked 2026-10-09 supports the bounded platform facts, not admission of any real workload.

The invoice-dispatch system below is fictional. Its obligations, components, numbers and deadlines are stipulated teaching inputs. No customer system was inspected, no database or AWS operation was executed, and no compatibility, latency, recovery or savings result is claimed. The reusable output is a group-boundary decision record, not a migration runbook or license opinion.

1. Replace the server count with a service obligation

The sponsor's useful question is what can change placement while continuing to deliver the required service. “Move one SQL Server” does not identify that service. A host may contain several unrelated databases, and one database may support several applications with different deadlines. Counting servers can help procurement estimate resources, but it cannot decide which responsibilities may be separated.

Write an obligation that can be accepted by someone outside the migration team. For the fictional example, invoice dispatch means accepted invoice requests are recorded, a dispatch batch for the agreed business cut is published, and its intended consumer acknowledges the correct batch before the agreed deadline. The obligation includes recovery from an uncertain send. Merely restoring the invoice tables satisfies none of the delivery statements by itself.

Distinguish mandatory outputs from conveniences before comparing targets. A diagnostic dashboard might be temporarily unavailable with an approved exception. A statutory or contractual export cannot be silently demoted because its implementation is awkward. Where an obligation is negotiable, record who can change it and the new acceptance criterion. An architecture team cannot retire a business output by omitting its node from the proposed diagram.

This gives the sponsor a finite decision population. Start with one obligation and its declared dependencies, rather than promising a graph of the entire enterprise. State the review window, exceptional schedules and known coverage gaps. If a quarter-end contributor is unobserved, the group is incomplete for a quarter-end claim even when the normal daily path is well understood.

2. Define a group and the edges that can cross it

A contribution is a required unit of behavior: accept a request, calculate an identifier, create an output, acknowledge delivery or restore the service. A dependency edge identifies what another contribution needs from it, including identity, data, timeliness and failure handling. A placement group is the set proposed to share a migration decision. It need not equal a process, host or application name.

Call a group obligation-complete when its required contributions are accounted for, including dependencies outside it. Completeness does not mean moving the whole connected enterprise at once. An external identity service can remain outside if the proposed users have an accepted identity and recovery contract. Conversely, two processes with separate owners may belong together when splitting them creates an unsupported behavior or an untested timing dependency.

AWS portfolio guidance separates dependency groups from waves and warns that network information alone cannot classify hard dependencies or establish latency tolerance. Use communication data as evidence of a relationship, then ask the owners what fails when it is delayed or unavailable. A frequently contacted monitoring service is not automatically a reason to migrate every application together.

A cut edge is a dependency that crosses the proposed placement boundary. Each needs a contract with an owner, accepted behavior and evidence. A missing edge contract holds that particular alternative; it does not prove the two components can never be separated. A reviewed redesign can change the edge. Record that as a new proposal rather than pretending the original grouping was already safe.

3. Consume the inventory without turning this into another discovery playbook

Use the SQL and Windows owners' dependency register as input. It should identify the relevant jobs, services, files, identities, consumers and exceptional branches, with coverage limitations. The companion playbook, Inventory SQL Server Host Dependencies Before Choosing RDS, describes how to collect that inventory and assign supported, externalized, replaced, retired or held dispositions. This paper asks what those dispositions do to the whole proposed placement.

For each required contribution, join its disposition to a business obligation and its proposed operating owner. “Externalize exporter” is not an owned output if nobody has agreed to build and operate the replacement. “Retain reporting” is incomplete if its data source is being retired. Preserve evidence references rather than copying sensitive commands, credentials or payloads into the sponsor's paper.

Do not discard dependencies solely because they are shared. AWS's portfolio baseline guidance cautions against false dependency groups created by common infrastructure. That is a reason to distinguish shared-service prerequisites from co-migration requirements, not a reason to ignore authentication, backup or monitoring. Name the shared service, required readiness and failure owner outside the move group.

Before constructing alternatives, reconcile the population with its owners. Ask whether any contribution has no consumer, any consumer has no producer, or any retained producer has lost its required data path. These are scope questions. They do not require reproducing the inventory commands, running jobs or granting access. An unexplained absence remains UNKNOWN and enters every affected alternative's gate.

4. Separate platform facts from workload admission

Standard RDS does not provide direct Windows host access, and importing msdb is not supported. Restoring user databases therefore cannot transfer the complete host's operating state. AWS SQL Server overview These facts establish a responsibility boundary, not a verdict on every job or integration. Review the required behavior against the exact supported service configuration.

Two concrete constraints matter to this example. Command-line and PowerShell execution through RDS SQL Server Agent are not supported. Separately, CLR is not supported on standard RDS SQL Server 2017 and later, including the proposed 2019 target. Agent guidance, feature restrictions A required host exporter or CLR calculation would need a reviewed replacement, external execution design or a different target. Do not infer that a safe-looking assembly is admissible from its permission label.

The current RDS version list includes SQL Server 2019 and documents version enumeration. A general listing is not evidence that the intended exact proposal was checked. Pin edition, engine string, Region, instance class, availability mode and relevant options before admitting it. Leaving the minor unspecified permits a default that may not match the evidence packet.

Self-managed hosting is also a proposal, not a compatibility certificate. Keeping Windows and the same engine major can reduce some redesign demands, but OS, build, identities, storage, network and recovery still require review. This paper offers no instruction to copy a host or assume that software, support agreements or license entitlements transfer with it.

5. Apply feasibility gates before preference scores

Evaluate every alternative against the same obligation population. Gate one is coverage: all required contributions and known exceptions are represented. Gate two is behavior and support: the proposed execution surface supports each required behavior, or a changed implementation has its own evidence. Gate three is boundary ownership: every new cut edge has an accepted contract and funded owner. Gate four is operability: identity, monitoring, recovery and support responsibilities are staffed. Gate five is permission and commercial feasibility: required approvals, entitlements and terms have been established by the appropriate owners.

Use three outcomes per gate: evidenced candidate, explicit conflict, or UNKNOWN. “Evidenced candidate” means the reviewed evidence supports the bounded design claim. It does not authorize production movement. A conflict rejects the current revision, while UNKNOWN identifies missing evidence. Both prevent that revision from winning a preference comparison. An average of five green fields and one required conflict is still a held alternative.

Once the gates are satisfied, compare consequences that can reasonably be traded: implementation effort, ongoing workload ownership, transition exposure, change flexibility and whole-scope cost. Keep the sponsor's weighting separate from factual feasibility. A sponsor may prefer higher recurring infrastructure expense to an urgent redesign, but cannot turn an unsupported required operation into support by weighting cost more heavily.

Record which evidence would reverse the ranking. If a supported exporter replacement removes the managed option's largest transition cost, the preferred option may change. If a retained host cannot meet the required support horizon, retention may cease to be feasible. This makes the record useful after new information arrives instead of freezing an attractive architecture slide into a permanent decision.

6. Alternative A: managed database with external responsibilities

In alternative A, the proposed database lives on standard RDS and the host-dependent dispatch contribution becomes a separately operated worker. The application, worker, database and downstream consumer are still one obligation population even though they have different execution surfaces. The promise is reduced responsibility for the managed database host, not disappearance of all system operations.

The operating model must say who owns the external worker's code, execution identity, releases, schedule, output custody, retry and incident response. It must also say which database operations remain customer responsibilities under the chosen service. A managed database invoice does not include an implicit engineering team for the replacement exporter. That replacement's funding and evidence are part of alternative A's scope.

Compare the new worker boundary deliberately. A source routine may previously have read local state with the host's identity; a remote worker now needs an explicit database role, network path and output authority. Its failure can occur after reading the batch but before acknowledging publication. The decision record needs the accepted behavior and the owning implementation plan. It should reference the mechanism owner's test evidence rather than inventing a generic distributed transaction solution.

Alternative A is a strong candidate when unsupported host behavior can be removed or replaced within the approved change budget, the replacement is independently accepted, and the whole obligation has a viable operating owner. Hold it when the target admission is incomplete, a required behavior cannot change, or the supposed operations benefit depends on an unstaffed external component. A restored database alone cannot close those holds.

7. Alternative B: retain a self-managed responsibility group

Alternative B keeps the database and required host contributions under a self-managed Windows/SQL Server boundary. Retention can mean remaining on the current approved platform. Relocating an intact group to self-managed cloud hosting is a separate variant that needs its own target and commercial assessment. Do not let one column called “retain host” blur staying in place and moving to a different operating environment.

The case for retention is continuity of a required behavior whose redesign is not currently acceptable, or a change budget better spent on another constraint. The cost is continued responsibility for the host, engine servicing, recovery, access and on-call model. Record whether the organization actually possesses that capability. Familiarity is not evidence that patching, restore or incident response meets the intended service contract.

Retention needs a horizon and funded exit or renewal decision. Microsoft's SQL Server 2019 lifecycle shows mainstream support ended in 2025 and extended support ends in 2030. That broad lifecycle is not a determination of the actual OS, build, application vendor or contract support. Check each separately. The sponsor should see the next support decision while comparing migration effort, rather than discovering it after choosing a cheap first year.

Reject retention when it depends on an unacceptable security or support exception, when the original facility must close before a viable group move, or when required operating ownership is unavailable. Retention is not the default safe fallback merely because the source is running today. Equally, do not call it architectural failure when it is the only evidenced option that meets the obligation and horizon.

8. Alternative C: stage the application move, retain database authority

Alternative C moves only a separable application contribution while retaining the database and host-dependent dispatch group. This can create useful progress before a managed redesign is ready, provided the newly remote application has an accepted dependency contract. State plainly that database retirement has not occurred. Calling the first stage “migration complete” conceals the obligations still tied to the retained platform.

This option is different from leaving an arbitrary half of the system behind. Select the cut because its behavior can be specified, observed and operated. If the moved application performs many sequential database exchanges on a user request, a cross-site path may change its completion behavior. Network reachability and a successful login do not establish the accepted response time, interruption behavior or recovery. No universal latency threshold is offered here.

Use the proposed path, driver, authentication, encryption and reconnect behavior in a bounded rehearsal specification. AWS SQL Server connection-encryption guidance describes service and client configuration; it does not certify a particular client's identity validation or application behavior. For a retained non-RDS database, obtain its own supported connection contract. Do not transpose an RDS parameter to a self-managed host.

Stage C should name the temporary operating period, dual-environment ownership, review date and evidence needed for the next stage. A deadline without funded exit work is only a calendar reminder. If the application cannot tolerate the new dependency path, enlarge the group or defer that stage. Keeping database authority together does not remove network or availability risks for the moved consumer.

9. Work through one fictional invoice-dispatch group

The stipulated system has six contributions. P accepts portal requests. D stores invoice and dispatch state. H prepares a dispatch batch using a Windows host executable called from an Agent command step. F holds the completed dispatch file. C acknowledges the received batch. Q consumes only already published batches for a diagnostic view. Identity and monitoring are external shared services with separately required readiness. No actual executable, schema, customer or endpoint is represented.

For the teaching case, P must receive an accepted response within a business-defined limit that is not yet supplied. D/H/F/C together must deliver one agreed daily batch by 06:00 UTC. Q may be unavailable for one approved day. The example deliberately leaves the portal timing limit UNKNOWN. The exception for Q is stipulated; it is not permission to drop a real reporting requirement.

The declared edges are P to D for request recording; H to D for the agreed batch population; H to F for completed output; F to C for delivery and acknowledgment; and Q to the published output. H's command-step execution conflicts with retaining it unchanged on standard RDS. Its replacement is a proposal with no observed execution. These inputs make alternative A held, even though no database feature conflict is stipulated for D itself.

Alternative B retains D/H/F together and preserves the declared execution shape. It is still held pending real support, identity, recovery and commercial evidence. Alternative C keeps D/H/F together and moves P only. It is held because the new P-to-D path lacks an accepted timing and failure contract. There is no winner in this initial packet. The defensible immediate decision is to fund the smallest missing evidence that distinguishes the options, not to score fictional green boxes.

Figure 1. Illustrative staged-placement responsibility view, not deployed AWS topology. D, H and F remain together; moving P creates a request-path cut requiring its own contract. Delivery to C and Q's approved exception remain accounted for. Identity and monitoring readiness are prerequisites outside this focused view.

Open the full-size responsibility diagram.

The figure's group encloses responsibilities, not a single transaction or guaranteed failure domain. H/F may be separate processes or storage resources in a real design. An arrow means the declared dependency named in the text; it does not assert a protocol, an automatic retry or an atomic transfer. This distinction prevents the convenient group box from becoming unsupported runtime architecture.

10. Compare whole-scope economics over the same horizon

Cost the same obligation for the same period and service requirements. Include recurring platform and support costs, ongoing operating effort, redesign and test work, temporary coexistence, network paths, retained dependencies and eventual retirement work. Identify quantities and unit-rate sources separately. A current provider price is not the workload's total cost; a personnel estimate is not an observed invoice.

Use a simple planning identity: whole-scope cost equals one-time change work plus recurring cost over the chosen horizon plus transition-specific cost plus explicitly retained obligations. Keep uncertain components as ranges or UNKNOWN, with their estimation owner. Do not replace an absent estimate with zero. Avoid adding speculative incident losses to manufacture a financially precise ranking.

For a small arithmetic illustration only, assume a twelve-month horizon and one fictional cost unit. A has 90 units of change work, 11 per month of combined database/worker operations and 24 transition units. B has 20 change units, 15 per month and 4 transition units. C has 40 change units, 17 per month across both environments and 18 transition units. Totals are A: 246, B: 204 and C: 262. These are stipulated inputs, not AWS prices, staffing rates, estimates, savings or benchmarks.

At twenty-four months with every other assumption unchanged, the totals become 378, 384 and 466. A/B arithmetic crosses at 22.5 months from the start: their one-time difference is 90 units and recurring difference is four units monthly. That comparison matters only if both designs have passed feasibility gates and the rates remain valid. The initial example has not passed those gates, so even the lowest twelve-month total selects nothing.

Ask what each number excludes. A's external worker must not be omitted because it belongs to an application budget. C's retained platform must not disappear from the total after the portal moves. B's future support work cannot be assumed free. Have the sponsor review the horizon, fixed versus variable commitments, currency/time basis and sensitivity before interpreting the arithmetic commercially.

11. Treat licensing, identity and recovery as separate evidence

Licensing is a gate owned by an appropriately qualified commercial or licensing reviewer. AWS RDS licensing guidance is a starting source for the service's models, not an assessment of an organization's entitlements. This paper makes no BYOL, mobility, tenancy or license-included recommendation. The retained/relocated variant needs its own evidence; a source license record cannot silently authorize a new hosting arrangement.

Identity review follows the changed responsibility boundaries. The worker's database rights, file authority, downstream credentials, evidence-store access and operator actions need accountable owners. Give the sponsor the changed access surface and unresolved decision, not secrets or a broad instruction to grant administrator access. A test using an exceptional powerful identity does not establish that the intended production role can perform the accepted behavior.

Recovery also follows the whole obligation. A database restore may recover D while leaving F's publication custody or C's acknowledgment unresolved. Require a recovery claim that identifies the intended service state, responsible operators and retained evidence across those contributions. The data reconciliation paper owns business invariants and aligned cuts; use its output instead of substituting row totals for recovered dispatch.

The migration strategy guide owns writer transfer and the change in recovery after target writes. This paper does not select a replication tool, approve bidirectional writes or promise automatic rollback. A placement decision creates the scope for a later migration and recovery design. That later evidence can invalidate the placement if the proposed group cannot meet its accepted requirements.

12. Use a decision path that reopens when the boundary changes

First establish the obligation and declared coverage. Next evaluate each placement's support and cut edges. Only candidates with evidence-backed gates enter consequence comparison. Independent reviewers then accept or reject the proposed scope, with an evidence expiry or invalidation rule. Operational authorization remains a later decision. This ordering prevents a preferred target from deciding which inconvenient dependencies count.

Figure 2. Decision-state view, not execution steps. HOLD preserves missing or conflicting evidence. A changed contribution, target or cut contract reopens the affected scope gates, even after a previous comparison. Scope review does not authorize migration.

Open the full-size decision diagram.

Choose invalidation conditions concretely: new writer, changed exporter revision, different target minor or option, new downstream consumer, revised deadline, changed identity, expired commercial assumption or a different network path. Revisit affected edges and consequences. A change limited to one contribution need not reopen unrelated evidence, but the reviewer should justify that boundary rather than assume it.

Do not keep a held option in limbo without an owner. Record the smallest next artifact, who may produce it and when it will be reviewed. If no authorized test or supported replacement can answer the conflict within the decision window, remove that revision from the comparison and explain the remaining choices. A clear deferral can be a senior decision; an unexplained UNKNOWN presented as a completed plan cannot.

13. Complete the filled record, then copy the blank one

The filled record is a teaching packet. References are fictional aliases, not authenticated evidence or approvals. Every real-world gate remains held. Its useful result is the next evidence request, not target selection.

Obligation and decision owner

invoice-dispatch-r1; sponsor-role-a. Accepted requests, correct daily dispatch batch and consumer acknowledgment by 06:00 UTC. Portal timing limit UNKNOWN.

Population and coverage

P, D, H, F, C, Q; declared edges in section 9; shared identity/monitoring prerequisites. Fictional finite population, real coverage UNKNOWN. Q's one-day exception stipulated.

Environment profile

Self-managed Windows/SQL Server2019Standard to proposed standard RDS2019Standard. Exact source/target profiles and hosting details UNKNOWN.

A: managed boundary

D on proposed RDS; H replaced externally; F/C delivery contract retained. H unchanged conflicts with managed Agent execution. Replacement evidence and owner commitment missing. HOLD.

B: retained boundary

D/H/F self-managed together; P and downstream obligations accounted for. Current-host retention only; cloud rehosting not assessed. Support, recovery and commercial gates UNKNOWN. HOLD.

C: staged boundary

Move P; retain D/H/F authority. P-to-D timing/failure contract UNKNOWN. Whole database retirement explicitly deferred. HOLD.

Common comparison basis

Twelve months, fictional units only. A246, B204, C262. Twenty-four-month sensitivity A378, B384, C466. No preference ranking while gates held.

Security, recovery and commercial gates

Qualified reviewers unassigned; actual identities, recovery observations, licensing and terms UNKNOWN. No rights or execution permission inferred.

Next decision and invalidation

Request H replacement scope/ownership and P-to-D accepted requirement plus authorized rehearsal specification. Reopen on changed population, target, cut contract, support horizon or costs. Independent scope review pending.

Use the following fields for each real obligation. Keep attachments controlled and versioned; publish opaque references where disclosure is inappropriate. Record one alternative's holds without erasing the others. A completed form is not evidence that its contents are true.

Obligation and decision owner

Enter accepted outputs, business cut, deadlines, permitted interruption/loss, accountable sponsor and requirement revision. Mark unknowns.

Population and coverage

List required contributions, dependency edges, exceptional schedules, consumers, shared prerequisites, exclusions and coverage owner/evidence.

Environment profile

Enter source OS/engine/build and proposed target edition/version, Region/account, topology/options and dated support evidence.

A: managed boundary

Place every contribution. List changed implementations and cut contracts, named owners, support/behavior evidence and separate gate outcomes.

B: retained boundary

Specify stay-in-place versus relocated self-managed variant, group members, operating capability, support horizon, evidence and gate outcomes.

C: staged boundary

Specify moved and retained members, authority, cross-boundary contracts, temporary ownership, exit funding, review date and gate outcomes.

Common comparison basis

Enter horizon, currency/time basis, quantities, rates, effort sources, retained/transition costs, uncertainty and sensitivities. Compare only feasible candidates.

Security, recovery and commercial gates

Reference actual identity/access review, whole-obligation recovery evidence, qualified licensing/terms assessment, reviewers and limitations.

Next decision and invalidation

Record chosen revision or deferral, rejected alternatives and reasons, smallest missing evidence, owner/date, independent review and invalidating changes. Keep execution authority separate.

14. Decision, limits and next steps

The initial fictional packet selects no target. Its next useful work is to clarify the portal requirement and cost/own a supported exporter replacement, while verifying the retained group's real support and operating basis. Those outputs distinguish the alternatives. Repeating a restore or producing a more detailed price table would leave the decisive scope questions unanswered.

This framework cannot discover hidden dependencies, authenticate owner statements, determine license rights, predict performance or prove migration recovery. Its obligation closure is only as complete as the reviewed population and contracts. Exact availability and documentation can change. Recheck the proposed service and support facts when choosing a real target and again before an authorized change.

Bring one completed group-boundary record to the sponsor, database/Windows owners, application owner and independent architecture reviewer. Ask each to identify the first unsupported contribution or unowned cut edge. Resolve that item before naming a winning target. Approve the bounded scope and its remaining work explicitly, then commission the compatibility, reconciliation and migration evidence under their own owners. This paper does not authorize a migration or a production change.