Self-Hosting Migration Readiness Scorecard

Contents

• Method
• The ten controls
• Evidence that counts
• Pilot-to-cutover workflow
• Reconciliation and rollback
• Use the outputs responsibly

Method

A SaaS-to-self-hosted migration is ready only when you can show controlled evidence across data, identity, integrations, operations, cutover, and rollback. Installing the target earns no readiness points. A working instance proves that installation succeeded; it does not prove that users, records, permissions, dependencies, or recovery procedures will work after migration.

The scorecard uses ten controls. Choose one answer for each:

• Yes = 10 points
• Partial = 5 points
• No = 0 points

The maximum score is 100. Evidence quality is not scored automatically. A polished note is not proof, and a high score cannot compensate for weak or untested evidence. Use the note for each control to record what was checked, what supports the answer, and what must happen next.

All processing occurs locally in your browser. The widget keeps a note per control, exports a dated JSON snapshot, and generates a normal dofollow HTML link containing the score and rating.

The score bands are OpenAlt’s disclosed rubric for organizing a migration conversation. They are not an industry standard, certification, prediction, or guarantee.

Score	Rating	Meaning
85–100	Ready with evidence	The main controls have proof and remaining uncertainty is bounded.
65–84	Close, gaps remain	Migration may be viable, but unresolved gaps need owners and dates.
40–64	High-risk gaps	Important failure modes remain untested or unowned.
0–39	Not ready	Build the migration foundation before planning production cutover.

A high score does not guarantee a successful migration. A lower score does not prove migration is impossible. The result shows whether your current plan relies mainly on demonstrated capability or on assumptions still waiting for evidence.

NIST describes contingency planning as preparation for recovering information-system services after disruption, with testing, training, exercises, and maintenance helping reveal weaknesses. That discipline applies here: treat migration as an operational change with a recovery path, not as a one-time installation. See the NIST SP 800-34 Rev. 1 contingency-planning guide.

The ten controls

Score what you can demonstrate today, not what you intend to complete later.

1. Inventory of users, data, integrations, and owners. Map accounts, records, files, automations, external services, dependencies, and accountable people. An item without an owner is a cutover gap.

2. Tested representative source export. Produce an export containing realistic records, relationships, attachments, permissions, timestamps, inactive accounts, and difficult cases. A clean sample can support a pilot but cannot replace a full export approach.

3. Validated target import. Load representative source data into the target and verify that it can be queried, edited, displayed, and used in priority workflows. A completed import job is insufficient if the records are present but unusable.

4. Identity and account-lifecycle design. Define sign-in, account matching, roles, groups, invitations, deprovisioning, service accounts, and recovery access. Test both a normal user journey and a joiner, mover, or leaver event.

5. Replacement or approved gaps for integrations. For every source integration, identify a target equivalent, manual process, temporary bridge, or accepted loss of function. “We will find an alternative” is not a replacement.

6. Capacity based on measured usage. Size the target using observed users, storage, traffic, job volume, concurrency, retention, and growth. Record how measurements were obtained and which peak conditions remain untested.

7. Working backup and restore on the target. Create a backup, restore it into a usable environment, and verify recovered data and configuration. A backup that has never been restored remains an assumption.

8. Monitoring of the user journey and dependencies. Check the service from the outside as a user would while watching the components it relies on. Google SRE guidance on monitoring distributed systems distinguishes user-visible checks from internal signals and emphasizes alerts that lead to action.

9. Owned cutover and acceptance checks. Name the cutover lead, technical operators, approvers, communications owner, and support route. Define acceptance: access works, key records reconcile, integrations respond, and users can complete priority tasks.

10. Reversible rollback window and stop conditions. Set a time-bounded period in which rollback remains practical. Define symptoms that trigger a pause or reversal, who can call it, what data must be preserved, and how users will be directed.

Evidence that counts

Strong evidence is dated, repeatable, tied to an owner, and connected to the control being scored. Useful evidence includes a command log, export manifest, test record, reconciliation report, access test, restore transcript, dashboard view, or signed acceptance checklist.

For every control, capture four short facts:

• What was tested?
• Which users, data, or workflow were included?
• What was the result?
• What remains open, and who owns it?

Use representative data rather than an idealized demonstration. Include empty fields, unusual characters, large records, deleted or inactive accounts, shared ownership, permissions, attachments, recurring jobs, and records crossing integration boundaries. Keep sensitive material out of shared notes and public links.

Export and import remain separate controls because they prove different things. Export evidence shows that the source can provide usable data. Import evidence shows that the target can receive, map, preserve, and operate on it. A source file may be complete while target mapping is wrong; a target may be healthy while the source export omits important content.

The ICO data portability guidance discusses structured, commonly used, machine-readable data and highlights secure transmission, third-party information, and limits on what is included. It is not a complete migration plan, but it is a useful prompt to document export contents, exclusions, and personal-data handling.

Pilot-to-cutover workflow

A staged workflow builds evidence before the migration becomes difficult to reverse.

1. Baseline the source. Freeze the inventory, identify owners, record current counts, and list workflows that cannot fail. Capture the source export format and operational constraints that affect timing.

2. Run a representative pilot. Select a bounded group of users and records containing ordinary and difficult cases. Import them into a non-production target, then test identity, permissions, integrations, search, edits, notifications, and reports.

3. Rehearse the full path. Perform a larger export and import with the intended tools and runbook. Measure elapsed time, operator effort, validation work, support needs, backup creation, restore time, and when new source changes must stop.

4. Set acceptance gates. Convert findings into explicit checks with owners. Proceed because known failures have a decision, workaround, or consciously accepted impact—not merely because the pilot felt smooth.

5. Cut over in a controlled window. Communicate the change, pause or limit source writes as planned, take the final export, import it, run reconciliation, test priority journeys, and obtain named acceptance before redirecting users.

6. Observe and maintain. Keep heightened monitoring and support during the rollback window. Record incidents, user reports, missed dependencies, and follow-up work. Update the runbook while details remain fresh.

This sequence aligns with the broader NIST emphasis on testing, exercising, and maintaining recovery plans as systems and organizational conditions change.

Reconciliation and rollback

Reconciliation is the release gate between “import finished” and “migration accepted.” Compare more than total record counts:

• users, groups, roles, and inactive accounts;
• record identifiers and relationships;
• attachments and file sizes;
• timestamps, ownership, and permissions;
• integration events and queued work;
• representative user journeys;
• records created or changed during the final export.

Classify each difference as an expected transformation, accepted loss, unresolved defect, or data still requiring transfer. Keep the report with the migration record.

Rollback is a timed decision, not a hopeful instruction. Before cutover, document:

• the last safe point for reversal;
• conditions that stop the migration;
• who can stop or roll it back;
• how source and target changes are tracked;
• how users are notified;
• how the target is preserved for diagnosis;
• how service is restored if rollback itself fails.

The NIST contingency plan glossary describes a contingency plan as management policy and procedures for responding to a loss of mission capability. Apply that principle directly: rollback needs a trigger, an owner, and usable procedures.

Use the outputs responsibly

The JSON export is a dated snapshot of your answers and notes. Keep it with the migration record and compare later snapshots when controls change. Do not treat an old score as current evidence.

The generated HTML link shares a concise result containing the score and rating through a normal dofollow link. Add context when publishing it: assessment date, target scope, major exclusions, and evidence review date. Do not present the link as proof that a migration is safe, complete, or endorsed.

For planning context, pair this scorecard with open-source alternatives, self-hosting for beginners, self-hosted software, and the backup storage calculator. The scorecard shows whether migration controls are ready; these resources help examine the platform, operating model, and storage consequences behind the result.