Interactive controls require the page scripts. If they do not appear,
reload this page. Static reference notes remain available below.
Every apocalypse needs a plan.
From Giles’s research to Willow’s testing spell: a Buffy-inspired SQL
Server migration learning guide. Every control below runs locally,
using illustrative examples rather than a live environment.
01 / Assessment
Research at the Library
Work through these four checks before comparing workloads or
rehearsing a cutover.
0 of 4 assessment steps complete
The Tome of Prophecies
Four illustrative assessment topics from the original teaching
guide. These are example review prompts, not findings from an actual
database scan. No DMA report or private system data is loaded.
Prophecy of Incompatibility
Review stored procedures and compatibility settings against the
intended target version. The original fixture concerns
compatibility; it does not establish that a real procedure is
incompatible.
Curse of Breaking Change
The original fixture names RAISERROR as a review
topic. Compare actual application code with the target-version
documentation and test its error-handling behavior. This example
does not establish a breaking change.
Glamour of Behavior Change
The original fixture names COUNT with an
OVER clause. Reconcile query results during workload
testing. No changed result or defect is asserted by this teaching
example.
Whispers of Deprecation
The original fixture names sp_dboption as a
legacy-feature review topic. Inventory any actual usage and verify
its status for the intended target version before planning a
replacement.
02 / Workload comparison
Illustrative data
Willow’s Testing Spell
Willow’s testing spell compares the original illustrative source and
target workload. Reveal the results to inspect the category counts; no
workload is captured or replayed.
Illustrative DEA results retained from the original guide
Result
Source
Target
Improved
0
953
Degraded
0
12
Errors
32
5
Stable
1222
284
Example only. These values demonstrate the comparison interface, not
a measured professional result.
03 / Dependencies
The Evacuation Convoy
The original three-role topology, with generic labels. It is an
illustrative teaching map, not an infrastructure inventory.
All three roles are connected. Review each application path rather
than treating a database as an isolated move.
Web + SQL ↔ API database
Web + SQL ↔ Data database
API database ↔ Data database
04 / Security
Fortifying Cleveland
Encrypts database files at rest. Validate certificate and key
backup procedures before migration.
05 / Cutover ritual
Averting the Apocalypse
Apply final log backups
Migrate application configuration
Deploy application code
Validate data and application behavior
Switch application traffic
Confirm service health
Retire the source after the agreed retention period
Ready for a local walkthrough.
Ask Giles: what should I check?
This is a scripted guide, not an AI service. Start with assessment
and dependencies, compare representative workloads, rehearse
rollback, then validate the whole application after cutover.
Reference notes & original examples
The original Buffy-themed guide is organized into five phases below.
The examples are historical teaching material, not an assessment of
a real migration. All demonstrations on this page run locally.
A Slayer’s guide, phase by phase.
Phase One: Research at the Library
Use the assessment checklist to plan the review, then expand each of
the four illustrative finding topics in
the Tome of Prophecies. The original
guide refers to Data Migration Assistant (DMA); no scan is performed
here.
Phase Two: Willow’s Testing Spell
Run the example workload comparison to
reveal the original source/target counts and charts. Its values are
illustrative, not measured performance results.
Choose a security topic to read about
encryption at rest, protected columns, HTTPS policy or auditing.
These explanations are review prompts, not a deployment checklist.
Phase Five: Averting the Apocalypse
Rehearse the seven cutover steps, inspect
the progress status, then reset the walkthrough. No systems,
application traffic or DNS records are changed.