crowd-funder-for-time-pwa/docs/migration-templates/COMPLETE_MIGRATION_CHECKLIST.md

Complete Migration Checklist - MANDATORY STEPS

Overview

This checklist ensures NO migration steps are forgotten. Every component migration MUST complete ALL sections.

⚠️ CRITICAL: Triple Migration Pattern

🔑 The Complete Pattern (ALL 3 REQUIRED)

1. Database Migration: Replace legacy databaseUtil calls with PlatformServiceMixin methods
2. SQL Abstraction: Replace raw SQL queries with service methods
3. Notification Migration: Replace $notify() calls with helper methods + constants

❌ INCOMPLETE: Any migration missing one of these steps ✅ COMPLETE: All three patterns implemented

Pre-Migration Assessment

[ ] 1. Identify Legacy Patterns

• Count databaseUtil imports and calls
• Count raw SQL queries (SELECT, INSERT, UPDATE, DELETE)
• Count $notify() calls
• Count logConsoleAndDb() calls
• Document total issues found

[ ] 2. Verify PlatformServiceMixin Setup

• Component already imports PlatformServiceMixin
• Component already has mixins: [PlatformServiceMixin]
• If missing, add mixin first

Phase 1: Database Migration

[ ] 3. Replace Database Utility Calls

• Remove import * as databaseUtil from "../db/databaseUtil"
• Replace databaseUtil.retrieveSettingsForActiveAccount() → this.$accountSettings()
• Replace databaseUtil.mapQueryResultToValues() → this.$mapQueryResultToValues()
• Replace other databaseUtil.* calls with mixin equivalents

[ ] 4. Replace Logging Calls

• Remove import { logConsoleAndDb } from "../db/index"
• Replace logConsoleAndDb() → this.$logAndConsole()

Phase 2: SQL Abstraction Migration

[ ] 5. Replace Raw Contact Operations

• SELECT * FROM contacts WHERE did = ? → this.$getContact(did)
• DELETE FROM contacts WHERE did = ? → this.$deleteContact(did)
• UPDATE contacts SET x = ? WHERE did = ? → this.$updateContact(did, changes)
• INSERT INTO contacts → this.$insertContact(contact)

[ ] 6. Replace Other Raw SQL

• SELECT * FROM settings → this.$accountSettings()
• UPDATE settings → this.$saveSettings(changes)
• Generic queries → appropriate service methods
• NO RAW SQL ALLOWED: All database operations through service layer

Phase 3: Notification Migration

[ ] 7. Add Notification Infrastructure

• Add import: import { createNotifyHelpers, TIMEOUTS } from "@/utils/notify"
• Add property: notify!: ReturnType<typeof createNotifyHelpers>;
• Add initialization: created() { this.notify = createNotifyHelpers(this.$notify); }

[ ] 8. Add Notification Constants (if needed)

• Review notification messages for reusable patterns
• Add constants to src/constants/notifications.ts
• Import constants: import { NOTIFY_X, NOTIFY_Y } from "@/constants/notifications"

[ ] 9. Replace Notification Calls

• Warning: this.$notify({type: "warning"}) → this.notify.warning(CONSTANT.message, TIMEOUTS.LONG)
• Error: this.$notify({type: "danger"}) → this.notify.error(CONSTANT.message, TIMEOUTS.LONG)
• Success: this.$notify({type: "success"}) → this.notify.success(CONSTANT.message, TIMEOUTS.STANDARD)
• Toast: this.$notify({type: "toast"}) → this.notify.toast(title, message, TIMEOUTS.SHORT)
• Confirm: this.$notify({type: "confirm"}) → this.notify.confirm(message, onYes)
• Standard patterns: Use this.notify.confirmationSubmitted(), this.notify.sent(), etc.

[ ] 10. Constants vs Literal Strings

• Use constants for static, reusable messages
• Use literal strings for dynamic messages with variables
• Document decision for each notification call

Validation Phase

[ ] 11. Run Validation Script

• Execute: scripts/validate-migration.sh
• MUST show: "Technically Compliant" (not "Mixed Pattern")
• Zero legacy patterns detected

[ ] 12. Run Linting

• Execute: npm run lint-fix
• Zero errors introduced
• TypeScript compiles without errors

[ ] 13. Manual Code Review

• NO databaseUtil imports or calls
• NO raw SQL queries (SELECT, INSERT, UPDATE, DELETE)
• NO $notify() calls with object syntax
• NO logConsoleAndDb() calls
• ALL database operations through service methods
• ALL notifications through helper methods

Documentation Phase

[ ] 14. Update Migration Documentation

• Create docs/migration-testing/[COMPONENT]_MIGRATION.md
• Document all changes made
• Include before/after examples
• Note validation results

[ ] 15. Update Testing Tracker

• Update docs/migration-testing/HUMAN_TESTING_TRACKER.md
• Mark component as "Ready for Testing"
• Include notes about migration completed

Human Testing Phase

[ ] 16. Test All Functionality

• Core functionality works correctly
• Database operations function properly
• Notifications display correctly with proper timing
• Error scenarios handled gracefully
• Cross-platform compatibility (web/mobile)

[ ] 17. Confirm Testing Complete

• User confirms component works correctly
• Update testing tracker with results
• Mark as "Human Tested" in validation script

Final Validation

[ ] 18. Comprehensive Check

• Component shows as "Technically Compliant" in validation
• All manual testing passed
• Zero legacy patterns remain
• Documentation complete
• Ready for production

🚨 FAILURE CONDITIONS

❌ INCOMPLETE MIGRATION if ANY of these remain:

• databaseUtil imports or calls
• Raw SQL queries (SELECT, INSERT, UPDATE, DELETE)
• $notify() calls with object syntax
• logConsoleAndDb() calls
• Missing notification helpers setup
• Validation script shows "Mixed Pattern"

🎯 SUCCESS CRITERIA

✅ COMPLETE MIGRATION requires ALL:

• Zero legacy patterns detected
• All database operations through service layer
• All notifications through helper methods
• Validation script shows "Technically Compliant"
• Manual testing passed
• Documentation complete

Templates and References

• Migration Template: docs/migration-templates/component-migration.md
• Notification Constants: src/constants/notifications.ts
• PlatformServiceMixin: src/utils/PlatformServiceMixin.ts
• Notification Helpers: src/utils/notify.ts
• Validation Script: scripts/validate-migration.sh

---

⚠️ WARNING: This checklist exists because steps were previously forgotten. DO NOT skip any items. The triple migration pattern (Database + SQL + Notifications) is MANDATORY for all component migrations.

Author: Matthew Raymer
Date: 2024-01-XX
Purpose: Prevent migration oversight by cementing ALL requirements