Migration readiness checklist
Build a migration plan around what actually needs to move.
Inventory source systems, map records and dependencies, and define the checks that must pass before cutover. Use the checklist to expose gaps while there is still time to address them.
Practical evaluation guidance. Check current Dayrook scope and evidence.
On this page7 sections
Illustrative decision map · not a product screenshot
Move only after source evidence survives a dry run.
Scope, mappings, dependencies, exceptions, and success checks are resolved before the legacy system is retired.
- 01Outcome
- 02Evidence
- 03Dependencies
- 04Dry run
- 05Reconcile
In brief
What to carry into the workflow
- Agree the business scope, owners, selected data region, and success evidence before connecting a source.
- Use a source-backed dry run to expose mappings, conflicts, unsupported fields, target prerequisites, and approvals.
- Install Dayrook beside the old RMM agent, verify coverage, and make removal a separate customer-approved step.
1. Define the migration outcome
Migration readiness begins with the operating state the MSP needs at the end—not merely a list of records to copy. Define which customers, sites, users, devices, tickets, policies, scripts, backups, Vault data, cloud inventory, and network inventory are in scope, and which histories can remain read-only evidence.
- Name one accountable migration owner and owners for each source system.
- Select the tenant, customer scope, and required US or EU data placement.
- Record the modules, object types, date ranges, and attachments that are in and out of scope.
- Choose whether each area should preserve the current method or move to the recommended Dayrook method.
- Define pass, partial, failed, and rollback or repair outcomes before execution.
2. Prepare source access and evidence
Dayrook can discover a source through working API credentials and documentation, or through a bounded supported API-definition upload. Credentials stay as purpose-bound secret references and are not sent to the migration planner. The planning path uses documented schemas and bounded discovery evidence rather than raw secret-bearing responses.
- Provide the approved base URL, authentication method, and least-privilege migration credentials or OAuth path.
- Gather current OpenAPI or Swagger documentation, supported export files, pagination rules, and provider rate-limit guidance.
- Confirm the source connection can be tested without a mutation.
- Identify unsupported endpoints, restricted objects, expiring access, and provider maintenance windows.
- Remove secrets from documents and exports before upload; keep raw credentials out of notes and tickets.
3. Inventory objects and dependencies
The discovery report should show available object types, approximate counts, schemas, dependency order, source identifiers, and gaps. Relationships matter: a site depends on its customer, a ticket may depend on customer and user mappings, and a device binding needs a real enrolled target agent.
- Review detected customers, sites, contacts, contracts, projects, tickets, scripts, users, invoice metadata, and active products.
- Review high-impact role groups and policies separately; require explicit permission and policy detail.
- Identify cloud, alert, backup-restore-point, device, network, and Vault targets that need existing Dayrook prerequisites.
- Define deduplication keys using source IDs and available stable identity evidence.
- Confirm dependency order and which objects may be imported only after another target exists.
4. Review a source-bound dry run
A dry run is the decision surface. It should bind the selected records to the exact source snapshot, show counts, conflicts, warnings, unsupported fields, target-setup requirements, and the proposed target method. Changed source state must invalidate approval rather than drift silently into execution.
- Resolve duplicate and ownership conflicts before approval.
- Review role, permission, policy, region, entitlement, and billing effects.
- Exclude every target-setup-required record from approval counts until its real prerequisite exists.
- Verify that secrets and restricted values are absent from AI planning evidence.
- Approve one immutable object set and record every high-risk action separately.
5. Execute, verify, and coexist
Execution should be idempotent, checkpointed, selected-region, and recoverable through finite retries and dead-letter handling. Completion requires target read-back, not simply a successful queue dispatch. Imported records should preserve source lineage so exceptions can be repaired without duplicating good work.
- Monitor imported, skipped, blocked, retrying, dead-lettered, and verified counts by object type.
- Compare source and target counts, required fields, relationships, and sampled customer-visible screens.
- Install the Dayrook agent alongside the old RMM agent and verify identity, check-in, policy, backup, and required coverage.
- Keep old-agent removal disabled until the customer explicitly approves a verified removal path.
- Close the project only with recorded repair actions, accepted exceptions, audit evidence, and owner sign-off.
Try this in your evaluation
Pilot acceptance before cutover
Illustrative scenario · use it to plan a test, not as proof of a result
Fictional pilot: plan 10 company records; reconcile 9 matches and 1 duplicate exception. The owner withholds go-live until the duplicate is resolved and a sample workflow passes.
Define a successful result
Check these support boundaries
- Source system and supported import objects
- Region, authority and secure credential handoff
- Counts, duplicates, history and exclusions
- Owners, reconciliation and retirement gates
Acceptance record
Record source count, imported count, exceptions, evidence, owner, dependencies, acceptance decision and deferred items. Keep credentials outside worksheets and inquiry messages.
Limits to resolve
The current migration directory evidences company-record scope where stated, not universal ticket/history import. Agent coexistence and deployment combinations require a release-specific pilot.
Questions, answered
Questions to resolve before your next step.
What should block a migration?
Unknown source behavior, missing authority, unresolved destructive changes, failed reconciliation, or absent recovery plans should stop progression.
Can Dayrook migrate an unsupported tool?
A source can be evaluated through documented APIs and discovery, but unsupported or inaccessible behavior must be reported rather than guessed.
When should old agents be removed?
Only after Dayrook coverage and imported state are verified and the customer approves the retirement step.