11. Data Migration

Data Migration Overview

VNA's existing Meals on Wheels operations depend on data that currently lives across multiple legacy platforms. Phase 1 therefore requires a deliberate migration workstream rather than treating conversion as a final-load task near go-live. The objective is to move the data VNA needs for operational continuity, reporting, billing support, compliance, and day-to-day user adoption into the new platform in a controlled, testable way.

Based on the VNA-provided migration workbook, the primary migration burden sits in Netsmart and OnBase / AllDocs, with a lighter conversion scope expected for RoadNet and any supporting operational reference data. The current workbook indicates approximate Meals on Wheels volumes of 55,637 distinct patients, 25,895,921 service or visit records, 31,666 assessments, 4,917 clinical notes, 1,230,267 claims, and roughly 21.3 GB of MOW-related document content. Those figures are sufficient for planning, but the final migration scope and conversion design should still be confirmed during discovery and profiling.

Migration Scope and Source Systems

The Phase 1 migration scope should focus on Meals on Wheels data only, even though some of the legacy source platforms contain records for other VNA programs as well. The main in-scope source systems are expected to be:

1. Netsmart

   This is the primary structured-data source for client records, services, assessments, notes, billing-related history, and other operational data needed to support the new platform.

2. OnBase / AllDocs

   This is the primary document source and should be treated as both a content migration and an indexing / document-association migration problem.

3. RoadNet

   Migration from RoadNet is expected to be limited primarily to active routing configuration and related setup data rather than historical route-execution detail.

4. BOP and related VNA-managed assets

   These may serve as supporting reference sources, bridge points, or validation inputs where they help confirm migrated values or preserve continuity for existing operations.

The final migration inventory should identify exactly which entities, date ranges, attachments, and historical records will move into Phase 1 production and which items, if any, will remain in legacy systems for reference only.

Migration Approach

The migration should be run as a formal workstream alongside application build, testing, and implementation planning. In practical terms, that means migration work should start early and move through a repeatable sequence:

1. confirm the in-scope data domains and legacy source systems
2. profile the source data and review the available extracts and documentation
3. define the target mappings, transformations, and business rules
4. execute one or more mock conversions into non-production environments
5. validate, reconcile, and correct defects or rule gaps
6. prepare and execute the production cutover migration

This is the safest approach for a project of this size because it gives the team time to discover data-quality issues and mapping edge cases before the go-live window.

Discovery, Profiling, and Data Quality

The VNA migration workbook already notes two important realities: the Netsmart data dictionary has not yet been fully provided, and direct database access may depend on what access VNA can obtain from its current hosting arrangement. That means the migration effort should begin with structured source-system discovery and data profiling rather than assuming the source structure is already fully known.

That profiling effort should confirm:

1. source table and field availability
2. field meanings and code-set usage
3. record volumes and date ranges
4. orphaned or incomplete records
5. duplicate client files and conflicting identifiers
6. address-quality issues and other known data anomalies

Known data-quality issues should be surfaced, reviewed with VNA, and handled through explicit cleansing and business-rule decisions or translated in migration logic so that the migrated data is operationally usable on day one.

Mapping, Transformation, and Conversion Rules

Each migrated data domain should have an agreed mapping from source values into the new target structure. This includes field-to-field mapping, code translation, defaulting rules, handling of inactive or legacy-only values, document association rules, and any transformation logic required to fit the new data model.

The conversion design should also distinguish between:

1. records that must be fully migrated for active Phase 1 operations
2. records that should be migrated primarily for history, reporting, or audit continuity
3. records that may remain in legacy systems if they are not needed in the operational baseline

Document Migration

Document migration should be handled as its own stream within the broader migration effort. For OnBase / AllDocs, the core requirement is not just to copy files, but to preserve the metadata and record associations that allow users to find the right document from the right client or workflow context.

The initial migration plan should therefore focus on:

1. extracting document files and their indexing metadata
2. linking documents correctly to the migrated client and service records
3. validating document counts and sample retrieval results
4. confirming which document categories are required in Phase 1 production

If expanded search behavior, OCR enrichment, or other document-management enhancements are desired beyond basic indexed retrieval, those should be confirmed separately from the core migration obligation.

Mock Conversions, Validation, and Reconciliation

The production migration should be preceded by one or more mock conversions into non-production environments. These rehearsal runs are necessary to validate extraction logic, transformation rules, data quality handling, load performance, and business usability before go-live.

Each mock conversion should include structured reconciliation, including:

1. source-to-target record counts
2. spot checks of critical business records
3. validation of key relationships and document links
4. exception reporting for failed, skipped, or transformed records
5. business review of migrated samples by VNA subject-matter users

Migration should not be considered ready for production until the team can demonstrate that the converted data is materially complete, explain any intentional exclusions, and show that the unresolved exceptions are understood and acceptable.

Cutover and Production Migration

The final migration should be tied directly to the broader implementation cutover plan. That plan should define the final extraction window, any required data-freeze period, sequencing between structured data and document loads, validation checkpoints, and the approval path for moving from migrated production data into live use.

As a practical matter, the production migration should include:

1. a final pre-cutover validation of migration scripts and environment readiness
2. a controlled final extract from the approved source systems
3. sequenced production loads and post-load checks
4. business and technical reconciliation before release approval
5. clear rollback or contingency decision points if critical migration issues are discovered

Until the production cutover is validated and approved, the legacy environment should remain the reference point for recovery and comparison.

Migration Assumptions and Dependencies

The migration plan depends on several inputs that must be resolved early enough to avoid schedule pressure later in the project:

1. timely access to source-system extracts, schema details, and document inventories
2. confirmation of the final in-scope MOW entities, history windows, and document categories
3. VNA stakeholder participation in mapping decisions, data-cleansing rules, and validation review
4. availability of non-production environments for repeated mock conversions
5. alignment between migration sequencing, testing, training, and go-live planning

For that reason, migration should be treated as a first-class delivery stream in Phase 1, with explicit planning, ownership, testing, and readiness controls rather than being deferred to the end of the implementation.