Here is the honest situation. Here is the honest situation. SQL Server migrations rarely fail because the data does not move. Moving the data is the mature, well tooled, well rehearsed part, and it usually works. They fail because everything around the database is invisible in a backup, and because the plan was written against the estate as it was designed rather than the estate as it has been running. The first failure is discovery. The consumer list comes from architecture documents and from asking application owners, which surveys the people you already know and returns the dependencies you already listed. What is missing is the reporting job on a finance workstation, the integration authenticating as a service account nobody recognises, the monthly extract that only fires at period end and therefore never appears in a two week observation window. Those consumers discover the migration at cutover, and each one becomes an incident rather than a task. The second failure is that everything above the database is treated as detail. A backup is a complete copy of a database and nothing else, so server logins, server roles, linked servers, credentials, proxies, agent jobs with their schedules and operators, alerts, database mail, server-level triggers, audit specifications, encryption keys, trace flags, parallelism settings, collation and tempdb configuration all sit outside it. The restore succeeds, every row is present, and the application cannot log in, the overnight job never runs, and the alert that would have reported it was left behind on the old instance. Teams call these post-cutover snags because they were never on the plan, which is the whole problem. The third failure is a completion definition made of row counts. Counts are easy to produce and easy to put in a status update, and they survive a missing index, a dropped constraint, a reset identity seed, a restarted sequence, a trigger that did not script and a full-text catalogue that never came across. None of those change a count and all of them change behaviour, usually under load or at the next insert. The fourth failure is logins. A database user is bound to a login by an internal identifier, not by name, so recreating logins by hand orphans every user in every restored database. The symptom is confusing on purpose: the application connects, because the login is valid at the server, and then fails on its first statement, which reads as a permissions problem and gets repaired by granting something broader than the original. That is how a migration permanently degrades a permission model. Denies are worse, because a deny that was the only thing preventing access does not announce itself when it fails to migrate. The fifth failure is that authentication is treated as a build detail rather than a plan input. Cloud targets do not all support the authentication an instance inside your own domain supports, and the answer determines whether application teams have to change connection strings, whether a service account becomes a managed identity, and whether a group membership that quietly granted access still resolves. Decided late, it lands on other teams during the window. The sixth failure is compatibility level, the single setting most likely to change performance on the day, and the one most often left to whatever the restore produced. Raising it changes optimiser behaviour including cardinality estimation, so a plan that was stable for years changes shape and a report that ran in seconds runs for minutes. Leaving it low is not safe either, because later means never. And the testing that would have caught it is usually a smoke test, which proves the application starts and exercises none of the query shapes, data volumes or parameter values that produce a bad plan. Testing against generated data does not help, because plan choice follows the distribution of the real data and generated data has the wrong distribution by construction. The seventh failure is the cutover itself, which frequently exists as a shared understanding rather than a document. Stopping the application is not the same as stopping writers, because scheduled jobs, replication, integrations and one person with a query window are all writers, and a write that lands after the final log backup is not on the target, is not known to be missing, and surfaces as a reconciliation break days later. Nothing proves the last transaction on the source is the last transaction on the target unless somebody writes a sentinel and checks it. The eighth failure is rollback, which is genuinely available only until the first new write lands on the target. Teams write a rollback plan and never state when it stops being possible, so everyone believes there is an escape route for hours after it closed, and the go decision itself gets taken at two in the morning by people who are tired, invested and short of information, which always resolves as continue. The ninth failure is verification. The post-cutover check is performed by the person who did the migration, from their usual tool, with an administrative account, which succeeds on any instance that is running and therefore catches nothing. It bypasses exactly what breaks: the orphaned user, the missing role membership, the changed default schema, the firewall rule that permits the migration host and not the application host. The tenth failure is stabilisation. Jobs arrive enabled and still pointing at the source, so an extract or a payment file goes out from two instances at once and the duplicate is found by whoever received it. Backups, monitoring and alert routing were built for the old instance and do not follow, and the gap is invisible because an alert that no longer fires looks exactly like an alert with nothing to report. The source sits powered on holding live data, either unmonitored or switched off by somebody who assumed it was finished with. Where teams fall short is predictable: a consumer list from a diagram, a configuration rebuilt from memory, no performance baseline to argue from, a register that never existed, row counts standing in for parity, orphaned users repaired by over-granting, an identity decision taken during the build, a compatibility level nobody chose, a smoke test standing in for a regression test, writers assumed stopped, a rollback with no expiry, verification performed as an administrator, jobs armed on both instances, and an old server nobody has agreed to retire.
This Kit removes the guesswork. It is SQL Server migration planning written as adopt-ready controls you personalize in a weekend, with the evidence a change board, an infrastructure manager, an application owner or an internal auditor actually examines.
What you get, the moment you buy
Grounded in database administration and platform migration practice as it is actually run against production estates with real change windows and real Monday mornings. Editable Word and Excel files. This is a practitioner method and it is honest about what planning can and cannot remove from a cutover you only get to perform once.
What one control looks like
This is the opening control, where the plan either rests on the estate as it actually is or on the estate as somebody drew it. All 18 are built to this depth.
Why this is not another template pack
- The evidence is the point. A migration runbook and a backup are not evidence. This tells you what a change board, an infrastructure manager, an application owner or an internal auditor examines and where teams fall short, for every control.
- The hard specifics built in. A consumer inventory built from observed connection activity across a full cycle with a named owner per principal, a scripted instance configuration baseline held in version control and diffed against the target, a workload baseline in duration and resource cost for named queries and batches, an explicit register of every object that does not travel inside a backup covering logins, roles, linked servers, credentials, proxies, agent jobs, operators, alerts, mail, server triggers, audit specifications, encryption keys, trace flags, parallelism settings, collation and tempdb, jobs read for embedded source references and created disabled, completion defined as scripted object and setting parity including sequences, identity seeds, filegroup layout and database-scoped configuration rather than row counts, certificates restored and test restored before the window, logins scripted with original security identifiers and password hashes with an orphan check recorded per database, an authentication model decided before the plan is costed with every principal that changes type mapped to the application change it forces, a permission difference report covering grants, denies, ownership and the database owner with over-privilege recorded, a compatibility level chosen deliberately with plan history enabled first, unsupported and behaviourally different features found before sign-off with functional loss signed by the business, plan regression tested by workload replay against representative data with statistics updated first, a numbered cutover runbook rehearsed end to end that stops every writer, confirms no open transactions by query and verifies a sentinel, redirection by configuration proven reversible, go and no-go criteria with named owners and a fixed decision time, a rollback with a stated expiry, verification as each application principal from its own network position, schedules confirmed to run exactly once with output as the proof, and backups, monitoring and alerting proven on the new platform with a dated decommission decision are written into the controls, not left generic.
- Built on real practice, not one person's opinion, grounded in how database estate migrations actually hold together against a change window and where that discipline usually breaks down.
- It compounds. This work shares its shape with disaster recovery testing, access review, capacity management and change control, so it feeds your wider operational model rather than ending with the migration.
Who buys this
Database administrators, migration leads, platform and infrastructure engineers, and the managers accountable for a SQL Server estate moving to a cloud target, who have to say what connects to each database, what does not travel inside a backup, whether a user will be orphaned on restore, which principals change authentication type, what the compatibility level does to existing plans, when the rollback expires, and how they will know on the Monday morning that nothing ran twice. Whether you are planning a first migration that has to be defensible to a change board or formalising a programme that has moved databases successfully and evidenced none of it, you save weeks and walk in with your discovery, instance-object, permission, compatibility, cutover and stabilisation controls structured.
Common questions
Is it really editable? Yes. Word and Excel files you own and adapt. No portal, no subscription.
Does it cover the whole practice? Yes. Inventory and dependency discovery, separating database migration from instance-level object migration, logins, users and permission fidelity, compatibility and plan regression, cutover design with go, no-go and rollback, and post-cutover validation and stabilisation each have their own controls with their own evidence.
Is this tied to one cloud, one target platform or one migration tool? No. The controls are principle-level, the discovery method, the non-travelling object register, the login and permission discipline, the compatibility and regression method, the cutover and rollback rules and the stabilisation checks, so they apply whether the target is a managed database service, a hosted instance or another data centre, and whatever you move the data with.
Does it tell me what thresholds to use? No, and it should not. Every tolerance, retention period, capture window, decision time and rollback expiry in the Kit is a number your organization sets and records. What the Kit gives you is the method, the evidence and the discipline that makes your own numbers defensible.
What if it is not for me? A 30-day money-back guarantee.
Instant digital download · 30-day money-back guarantee · The Art of Service Pty Ltd, GPO Box 2673, Brisbane QLD 4001 · support@theartofservice.com