Chapter 1: Migration Overview
Chapter Overview
What you'll learn:
- Why Betasky migrates agencies differently from a simple CSV and PDF import
- The three phases: collect, transform, import
- What your agency needs to provide
Audience: Agency administrators and intake staff planning a move to Betasky from Axxess or another legacy EMR.
Related: This guide is separate from the Betasky User Documentation. User docs teach daily product use; this guide explains what to export from your old EMR and what we load into Betasky.
1.1 The problem we solve
Home health agencies stay on legacy EMRs because of the data trap: fear of losing years of charts, medications, and episode history.
Betasky migration is designed to:
- Preserve history — discharged patients, closed episodes, visit note PDFs, and OASIS/POC documents remain searchable. When Betasky can read a visit PDF, it registers an archive visit on the episode timeline.
- Enable day-one operations — your active census gets structured data: patients, one current episode, medications, and forward scheduling in Betasky.
- Respect Betasky rules — we do not copy chaotic legacy timelines (Axxess Schedule Activity row-by-row) that would break episode logic, QA, or billing.
Your legacy EMR does not export Betasky-shaped data. Every migration uses a transformation step: you provide exports and PDFs; Betasky maps and validates them before go-live.
1.2 Three phases
| Phase | What happens | Your role |
|---|---|---|
| Collect | Exports from legacy EMR packed into one migration zip | You export and zip per Chapter 5 |
| Transform & validate | Betasky reviews zip, curates care orders, runs test imports | Joint review with your admin |
| Import | Load into Production in Waterfall order (Chapter 3) | Betasky executes; you verify (Chapter 6) |
Timeline: Migration targets 2 weeks after Betasky accepts a complete zip. Incomplete or problem zips extend the timeline until fixed (Chapter 16).
We do not bulk-import years of Axxess Schedule Activity as editable live visits. We do archive the PDFs and register visit history when documents support it.
1.3 Service levels
| Level | Who runs exports | Who maps data | Who validates |
|---|---|---|---|
| Self-service | Your agency | Your agency (Betasky templates) | Your agency + Betasky support |
| Guided | Your agency | Betasky + your agency | Joint sign-off |
| White-glove | Betasky (with your access) | Betasky | Betasky + your admin |
The same data tiers and Waterfall apply at every level. Only who executes each step changes.
1.4 What you send us
Typical deliverables from your agency:
- Patient list (active + discharged) with MRN and status as of cutover date
- Patient Profile PDF per MRN
- Medication Profile PDF for active patients
- Staff roster with emails — Employee List from Axxess Report Center (roles/permissions already in export)
- Physician, payer, pharmacy, and facility lists
- Schedule Activity PDFs — OASIS, visit notes, POC, orders (printed per row from Patient Chart)
- Joint curation of current episode dates for active patients
Chapter 5 is the full checklist. Part IV walks through a fictional Example Agency.
1.5 Environments
| Environment | Purpose |
|---|---|
| Sandbox | Training; demo data only — not your migrated census |
| Production | Your live Betasky agency after go-live approval |
Migration loads into Production once your Betasky agency exists and exports pass validation. See Chapter 4.
1.6 What success looks like
Before sign-off:
- Active census count matches your agreed cutover snapshot
- Each active patient has one correct current episode
- Medications and intake reflect legacy charts where imported
- Discharged patients are searchable; archive PDFs open on historical episodes
- Archive visits appear on episode timeline where PDFs were processed
- Staff logins and roles are correct
- Your admin completes the verification checklist (Chapter 6)
Next: Chapter 2 — Data Tiers