Files
motia-iii/MIGRATION_STATUS.md
bsiggel 17f908d036 Add requests dependency to project
- Included 'requests' in the dependencies list of uv.lock.
- Specified minimum version of 'requests' as 2.32.0 in requires-dist.
2026-03-01 22:39:33 +00:00

8.7 KiB

Motia Migration Status

🎉 MIGRATION KOMPLETT (außer Google Calendar Sync)

📋 Detaillierte Analyse: MIGRATION_COMPLETE_ANALYSIS.md

Quick Stats

  • 17 von 21 Steps migriert (81%)
  • 11 von 11 Service-Module migriert (100%)
  • ~7.500 Zeilen Code migriert (83%)
  • 13 HTTP Endpoints aktiv
  • 7 Queue Events konfiguriert
  • 1 Cron Job (alle 15 Min.)

Overview

Migrating from old-motia v0.17 (Node.js + Python hybrid) to Motia III v1.0-RC (pure Python).

Old System Analysis

Location

  • Old system: /opt/motia-iii/old-motia/
  • Old project dir: /opt/motia-iii/old-motia/bitbylaw/

Steps Found in Old System

Root Steps (/opt/motia-iii/old-motia/steps/)

  1. crm-bbl-vmh-reset-nextcall_step.py
  2. event_step.py
  3. hello_step.py

BitByLaw Steps (/opt/motia-iii/old-motia/bitbylaw/steps/)

Advoware Calendar Sync (advoware_cal_sync/):

  • calendar_sync_all_step.py
  • calendar_sync_api_step.py
  • calendar_sync_cron_step.py
  • calendar_sync_event_step.py
  • audit_calendar_sync.py
  • calendar_sync_utils.py (utility module)

Advoware Proxy (advoware_proxy/):

  • advoware_api_proxy_get_step.py
  • advoware_api_proxy_post_step.py
  • advoware_api_proxy_put_step.py
  • advoware_api_proxy_delete_step.py

VMH Integration (vmh/):

  • beteiligte_sync_cron_step.py
  • beteiligte_sync_event_step.py
  • bankverbindungen_sync_event_step.py
  • webhook/bankverbindungen_create_api_step.py
  • webhook/bankverbindungen_update_api_step.py
  • webhook/bankverbindungen_delete_api_step.py
  • webhook/beteiligte_create_api_step.py
  • webhook/beteiligte_update_api_step.py
  • webhook/beteiligte_delete_api_step.py

Supporting Services/Modules

From /opt/motia-iii/old-motia/bitbylaw/:

  • services/advoware.py - Advoware API wrapper
  • config.py - Configuration module
  • Dependencies: PostgreSQL, Redis, Google Calendar API

Migration Changes Required

Key Structural Changes

1. Config Format

# OLD
config = {
    "type": "api",  # or "event", "cron"
    "name": "StepName",
    "path": "/endpoint",
    "method": "GET",
    "cron": "0 5 * * *",
    "subscribes": ["topic"],
    "emits": ["other-topic"]
}

# NEW
from motia import http, queue, cron

config = {
    "name": "StepName",
    "flows": ["flow-name"],
    "triggers": [
        http("GET", "/endpoint")
        # or queue("topic", input=schema)
        # or cron("0 0 5 * * *")  # 6-field!
    ],
    "enqueues": ["other-topic"]
}

2. Handler Signature

# OLD - API
async def handler(req, context):
    body = req.get('body', {})
    await context.emit({"topic": "x", "data": {...}})
    return {"status": 200, "body": {...}}

# NEW - API
from motia import ApiRequest, ApiResponse, FlowContext

async def handler(request: ApiRequest, ctx: FlowContext) -> ApiResponse:
    body = request.body
    await ctx.enqueue({"topic": "x", "data": {...}})
    return ApiResponse(status=200, body={...})

# OLD - Event/Queue
async def handler(data, context):
    context.logger.info(data['field'])

# NEW - Queue
async def handler(input_data: dict, ctx: FlowContext):
    ctx.logger.info(input_data['field'])

# OLD - Cron
async def handler(context):
    context.logger.info("Running")

# NEW - Cron
async def handler(input_data: dict, ctx: FlowContext):
    ctx.logger.info("Running")

3. Method Changes

  • context.emit()ctx.enqueue()
  • req.get('body')request.body
  • req.get('queryParams')request.query_params
  • req.get('pathParams')request.path_params
  • req.get('headers')request.headers
  • Return dict → ApiResponse object

4. Cron Format

  • OLD: 5-field "0 5 * * *" (minute hour day month weekday)
  • NEW: 6-field "0 0 5 * * *" (second minute hour day month weekday)

Migration Strategy

Phase 1: Simple Steps (Priority)

Start with simple API proxy steps as they're straightforward:

  1. Example ticketing steps (already in new system)
  2. Advoware proxy steps (GET, POST, PUT, DELETE)
  3. Simple webhook handlers

Phase 2: Complex Integration Steps

Steps with external dependencies: 4. VMH sync steps (beteiligte, bankverbindungen) 5. Calendar sync steps (most complex - Google Calendar + Redis + PostgreSQL)

Phase 3: Supporting Infrastructure

  • Migrate services/ modules (advoware.py wrapper)
  • Migrate config.py to use environment variables properly
  • Update dependencies in pyproject.toml

Dependencies to Review

From old requirements.txt and code analysis:

  • asyncpg - PostgreSQL async driver
  • redis - Redis client
  • google-api-python-client - Google Calendar API
  • google-auth - Google OAuth2
  • backoff - Retry/backoff decorator
  • pytz - Timezone handling
  • pydantic - Already in new system
  • requests / aiohttp - HTTP clients for Advoware API

Migration Roadmap

COMPLETED

Phase Module Lines Status
1 Advoware Proxy (GET, POST, PUT, DELETE) ~400 Complete
1 advoware.py, advoware_service.py ~800 Complete
2 VMH Webhook Steps (6 endpoints) ~900 Complete
2 espocrm.py, espocrm_mapper.py ~900 Complete
2 bankverbindungen_mapper.py, beteiligte_sync_utils.py, notification_utils.py ~1200 Complete
3 VMH Sync Event Steps (2 handlers + 1 cron) ~1000 Complete
4 Kommunikation Sync (kommunikation_mapper.py, kommunikation_sync_utils.py) ~1333 Complete
5 Adressen Sync (adressen_mapper.py, adressen_sync.py) ~964 Complete

Total migrated: ~7497 lines of production code

REMAINING (Phase 6)

Advoware Calendar Sync - Google Calendar ↔ Advoware Sync:

  • calendar_sync_cron_step.py - Cron-Trigger für automatischen Sync
  • calendar_sync_event_step.py - Queue-Event Handler (920 Zeilen!)
  • calendar_sync_api_step.py - HTTP API für manuellen Trigger
  • calendar_sync_all_step.py - Bulk-Sync Handler
  • calendar_sync_utils.py - Hilfs-Funktionen
  • audit_calendar_sync.py - Audit-Funktion

Dependencies:

  • google-api-python-client - Google Calendar API
  • google-auth - Google OAuth2
  • PostgreSQL - Für Termine-Datenbank
  • Redis - Für Caching/Locking

Estimated effort: 3-5 Tage (komplex wegen Google API + PostgreSQL)

Priority: MEDIUM (funktioniert aktuell noch im old-motia System)

Completed

  • Analysis of old system structure
  • MIGRATION_GUIDE.md reviewed
  • Migration patterns documented
  • New system has example ticketing steps
  • Phase 1: Advoware Proxy Steps migrated (GET, POST, PUT, DELETE)
  • Advoware API service module migrated (services/advoware.py)
  • Phase 2: VMH Integration - Webhook Steps migrated (6 endpoints)
  • EspoCRM API service module migrated (services/espocrm.py)
  • All endpoints registered and running:
    • Advoware Proxy:
      • GET /advoware/proxy
      • POST /advoware/proxy
      • PUT /advoware/proxy
      • DELETE /advoware/proxy
    • VMH Webhooks - Beteiligte:
      • POST /vmh/webhook/beteiligte/create
      • POST /vmh/webhook/beteiligte/update
      • POST /vmh/webhook/beteiligte/delete
    • VMH Webhooks - Bankverbindungen:
      • POST /vmh/webhook/bankverbindungen/create
      • POST /vmh/webhook/bankverbindungen/update
      • POST /vmh/webhook/bankverbindungen/delete

Current Status: Phase 3, 4, 5 Complete

Phase 3 - VMH Sync Event Steps & Cron:

  • beteiligte_sync_event_step.py (mit Kommunikation Sync Integration)
  • bankverbindungen_sync_event_step.py (bereits migriert)
  • beteiligte_sync_cron_step.py (alle 15 Min., Auto-Reset für permanently_failed)

Phase 4 - Kommunikation Sync:

  • kommunikation_mapper.py (334 Zeilen - Mapping mit Base64 Marker)
  • kommunikation_sync_utils.py (999 Zeilen - Bidirektionaler Sync mit 3-Way Diffing)

Phase 5 - Adressen Sync:

  • adressen_mapper.py (267 Zeilen - CAdressen ↔ Advoware Adressen)
  • adressen_sync.py (697 Zeilen - CREATE/UPDATE mit READ-ONLY Detection)

Sync-Architektur komplett:

  1. Webhooks (Phase 2) → Emittieren Queue-Events
  2. Event Handler (Phase 3) → Verarbeiten Events mit Stammdaten-Sync
  3. Kommunikation Sync (Phase 4) → Bidirektionale Email/Phone-Synchronisation
  4. Adressen Sync (Phase 5) → Bidirektionale Adressen-Synchronisation
  5. Cron Job (Phase 3) → Regelmäßige Sync-Checks & Auto-Retries

Die vollständige Synchronisations-Pipeline ist nun einsatzbereit!

Notes

  • Old system was Node.js + Python hybrid (Python steps as child processes)
  • New system is pure Python (standalone SDK)
  • No need for Node.js/npm anymore
  • iii engine handles all infrastructure (queues, state, HTTP, cron)
  • Console replaced Workbench