{ "schemaVersion": "1.0", "item": { "slug": "afrexai-legacy-modernization", "name": "legacy modernization", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/1kalin/afrexai-legacy-modernization", "canonicalUrl": "https://clawhub.ai/1kalin/afrexai-legacy-modernization", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/afrexai-legacy-modernization", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-legacy-modernization", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-05-07T17:22:31.273Z", "expiresAt": "2026-05-14T17:22:31.273Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentDisposition": "attachment; filename=\"afrexai-annual-report-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/afrexai-legacy-modernization" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/afrexai-legacy-modernization", "agentPageUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Legacy System Modernization Engine", "body": "Complete methodology for assessing, planning, and executing legacy system modernization — from monolith decomposition to cloud migration. Works for any tech stack, any scale." }, { "title": "Modernization Brief", "body": "system_name: \"[Name]\"\nage_years: 0\nprimary_language: \"\"\nframework: \"\"\ndatabase: \"\"\ndeployment: \"on-prem | VM | container | serverless\"\nlines_of_code: 0\nteam_size: 0\nmonthly_users: 0\nannual_revenue_supported: \"$0\"\ncompliance_requirements: []\nknown_pain_points: []\nbusiness_driver: \"cost | speed | talent | risk | compliance | scale\"\ntimeline_pressure: \"low | medium | high | critical\"\nbudget_range: \"$0-$0\"\nsponsor: \"\"" }, { "title": "Technical Debt Inventory", "body": "Score each dimension 1-5 (1=critical, 5=healthy):\n\nDimensionScoreEvidenceCode quality — test coverage, complexity, duplicationArchitecture — coupling, modularity, clear boundariesInfrastructure — deployment automation, monitoring, scalingDependencies — outdated libraries, EOL frameworks, security vulnsData — schema quality, migration history, backup/recoveryDocumentation — accuracy, coverage, onboarding effectivenessOperations — deployment frequency, MTTR, incident rateSecurity — auth patterns, encryption, audit trail, compliance gapsDeveloper experience — build time, local setup, debugging toolsBusiness logic clarity — documented rules, test coverage of logic\n\nTotal: /50\n\n40-50: Healthy — incremental improvement\n30-39: Aging — targeted modernization\n20-29: Legacy — systematic modernization needed\n10-19: Critical — modernize or replace" }, { "title": "Dependency Risk Matrix", "body": "For each major dependency:\n\ndependency: \"\"\ncurrent_version: \"\"\nlatest_version: \"\"\neol_date: \"\" # End of life\nsecurity_vulns: 0 # Known CVEs\nupgrade_difficulty: \"trivial | moderate | hard | rewrite\"\nbusiness_risk: \"low | medium | high | critical\"\nalternatives: []\n\nPriority rules:\n\nEOL within 12 months → P0\nKnown unpatched CVEs → P0\n3+ major versions behind → P1\nNo active maintainer → P1\nEverything else → P2" }, { "title": "Modernization Strategy Decision Matrix", "body": "StrategyWhen to UseRiskCostSpeedDisruptionRehost (lift & shift)Datacenter exit, minimal changeLowLowFastLowReplatform (lift & optimize)Cloud benefits without rewriteLow-MedMediumMediumLow-MedRefactor (restructure)Good code, bad architectureMediumMediumMediumMediumRe-architect (rebuild patterns)Monolith→services, new patternsHighHighSlowHighRebuild (rewrite)Small system, clear requirementsVery HighVery HighVery SlowVery HighReplace (buy/SaaS)Commodity functionalityMediumVariableFastHighRetireNo longer neededNoneNegativeInstantLowRetain (do nothing)Working fine, other prioritiesNoneOngoingN/ANone" }, { "title": "Strategy Selection Decision Tree", "body": "Is the system still needed?\n├─ No → RETIRE\n├─ Yes → Is it a commodity (CRM, email, etc.)?\n│ ├─ Yes → REPLACE (buy SaaS)\n│ └─ No → Is the code maintainable?\n│ ├─ Yes → Is the architecture the problem?\n│ │ ├─ Yes → RE-ARCHITECT (strangler fig)\n│ │ └─ No → Is the infrastructure the problem?\n│ │ ├─ Yes → REPLATFORM\n│ │ └─ No → REFACTOR incrementally\n│ └─ No → Is the system small (<50K LOC)?\n│ ├─ Yes → Can requirements be clearly defined?\n│ │ ├─ Yes → REBUILD\n│ │ └─ No → REFACTOR + RE-ARCHITECT\n│ └─ No → STRANGLER FIG (never big-bang rewrite)" }, { "title": "The Big Rewrite Anti-Pattern", "body": "NEVER do a full rewrite of a large system. It fails 70%+ of the time because:\n\nThe old system keeps getting features — moving target\nHidden business rules only exist in code — they get lost\nTimeline always 2-3x longer than estimated\nTwo systems to maintain during transition\nTeam burns out before completion\n\nAlways use Strangler Fig instead. Replace piece by piece." }, { "title": "How It Works", "body": "Identify a boundary — a feature, page, or API endpoint\nBuild the replacement — new stack, new patterns\nRoute traffic — proxy/facade sends requests to new or old\nVerify parity — same behavior, same data\nCut over — remove the proxy, retire the old code\nRepeat — next boundary" }, { "title": "Strangler Facade YAML", "body": "facade_name: \"[API Gateway / Reverse Proxy / BFF]\"\nrouting_rules:\n - path: \"/api/users/*\"\n target: \"new-service\"\n status: \"migrated\"\n migrated_date: \"2025-01-15\"\n - path: \"/api/orders/*\"\n target: \"legacy\"\n status: \"planned\"\n target_date: \"2025-Q2\"\n - path: \"/api/reports/*\"\n target: \"legacy\"\n status: \"not-planned\"\n notes: \"Low priority, rarely used\"" }, { "title": "Migration Sequence Rules", "body": "Start with the easiest, most isolated module — build confidence\nThen the highest-value business capability — prove ROI early\nLeave the hardest, most coupled parts for last — team learns patterns first\nNever migrate auth/identity early — it touches everything\nMigrate data access layer before business logic — clean data = clean migration\nAlways keep the old system as fallback until new is proven" }, { "title": "Dual-Write / Data Sync Patterns", "body": "PatternWhenComplexityRiskDual writeBoth systems write simultaneouslyHighData inconsistencyCDC (Change Data Capture)Stream changes from old→new DBMediumLag, orderingETL batch syncPeriodic bulk syncLowStale dataEvent sourcing bridgeEvents from old, replay in newHighSchema mappingRead from new, write to oldTransition periodMediumRouting complexity\n\nGolden rule: Pick ONE source of truth. Never let both systems own the same data simultaneously." }, { "title": "Domain Discovery", "body": "Before splitting a monolith, identify bounded contexts:\n\nEvent Storming (preferred) — sticky notes for domain events, commands, aggregates\nCode analysis — find clusters of related classes/tables\nTeam analysis — which teams own which features?\nData coupling analysis — which tables are joined together?" }, { "title": "Bounded Context YAML", "body": "context_name: \"\"\ndescription: \"\"\nteam: \"\"\nentities: []\ncommands: []\nevents_published: []\nevents_consumed: []\ndatabase_tables: []\nexternal_integrations: []\ncoupling_score: 0 # 0=independent, 10=deeply coupled\nextraction_difficulty: \"easy | moderate | hard | very-hard\"\nbusiness_value: \"low | medium | high | critical\"" }, { "title": "Extraction Priority Matrix", "body": "Plot contexts on: Business Value (Y) × Extraction Difficulty (X)\n\nEasyModerateHardHigh value🟢 Do first🟡 Do second🟠 Plan carefullyMedium value🟢 Quick win🟡 Evaluate ROI🔴 Probably not worth itLow value🟡 If easy, why not🔴 Skip🔴 Definitely skip" }, { "title": "Service Extraction Checklist", "body": "For each service being extracted:\n\nBounded context clearly defined\n API contract designed (OpenAPI spec)\n Database separated (no shared tables)\n Authentication/authorization integrated\n Event publishing for cross-service communication\n Circuit breaker for calls back to monolith\n Monitoring and alerting configured\n Deployment pipeline independent\n Feature flag for traffic routing\n Rollback plan documented\n Performance baseline captured (before/after)\n Data migration script tested\n Integration tests with monolith passing\n Runbook for on-call written" }, { "title": "Database Migration Strategies", "body": "StrategyDescriptionDowntimeRiskParallel runNew DB alongside old, sync bothZeroHigh complexityBlue-greenFull copy, switch DNSMinutesMediumRollingMigrate table by tableZero per tableMediumBig bangStop, migrate, startHoursHigh" }, { "title": "Schema Evolution Rules", "body": "Always additive — add columns/tables, never remove in the same release\nTwo-phase removal — Release 1: stop writing. Release 2: drop column (after backfill verified)\nDefault values always — every new column gets a default\nBackward compatible — old code must work with new schema during rollout\nIndex concurrently — never lock production tables\nTest with production-scale data — 100 rows ≠ 100M rows" }, { "title": "Data Quality Gates", "body": "Before migrating data:\n\ntable: \"\"\nrow_count_source: 0\nrow_count_target: 0\ncount_match: false\nchecksum_match: false\nnull_analysis: \"pass | fail\"\nreferential_integrity: \"pass | fail\"\nbusiness_rule_validation: \"pass | fail\"\nsample_manual_review: \"pass | fail\"\nperformance_benchmark: \"pass | fail\"\nrollback_tested: false\n\nRule: All gates must pass before cutover. No exceptions." }, { "title": "Cloud Readiness Assessment", "body": "Score each workload:\n\nFactorScore (1-5)NotesStateless designConfiguration externalizedLogging to stdoutHealth check endpointGraceful shutdownHorizontal scalabilitySecret management12-factor compliance\n\n35-40: Cloud-native ready\n25-34: Minor modifications needed\n15-24: Significant refactoring\n8-14: Major redesign required" }, { "title": "Cloud Migration Checklist", "body": "Network architecture designed (VPC, subnets, security groups)\n Identity and access management configured\n Data residency requirements verified\n Compliance mapping (cloud controls ↔ requirements)\n Cost estimation completed (TCO comparison)\n Disaster recovery plan updated\n Monitoring and alerting migrated\n DNS and certificate management planned\n CDN configuration\n Load testing in cloud environment\n Security scanning pipeline\n Backup and restore verified\n Runbooks updated for cloud operations\n Team trained on cloud platform\n Vendor lock-in assessment" }, { "title": "Cost Optimization from Day 1", "body": "Right-size instances — start small, scale up with data\nReserved/committed use — only after 3 months of usage data\nSpot/preemptible — for batch jobs, CI/CD, dev/test\nAuto-scaling — scale down at night, weekends\nStorage tiers — hot/warm/cold/archive based on access patterns\nTag everything — cost allocation by team, service, environment\nMonthly review — unused resources, oversized instances" }, { "title": "API Wrapping Pattern", "body": "For legacy systems without APIs:\n\nScreen scraping adapter — parse HTML/mainframe screens\nDatabase tap — read directly from legacy DB (read-only!)\nFile-based integration — watch folders, parse files\nMessage queue bridge — legacy writes to queue, new reads\nRPC wrapper — expose existing functions via REST/gRPC" }, { "title": "API Contract-First Migration", "body": "endpoint: \"/api/v2/orders\"\nlegacy_source: \"stored_procedure: sp_GetOrders\"\nnew_implementation: \"orders-service\"\nmigration_status: \"legacy | dual-run | new-only\"\ncontract_changes:\n - field: \"order_date\"\n old_format: \"MM/DD/YYYY string\"\n new_format: \"ISO 8601\"\n adapter: \"date_format_adapter\"\n - field: \"status\"\n old_values: [\"A\", \"C\", \"P\"]\n new_values: [\"active\", \"completed\", \"pending\"]\n adapter: \"status_code_mapper\"\nparity_tests: 47\nparity_passing: 47" }, { "title": "Migration Testing Pyramid", "body": "/ Smoke Tests \\ ← Whole system alive?\n / Parity Tests \\ ← Same behavior old vs new?\n / Integration Tests \\ ← Services work together?\n / Contract Tests \\ ← API contracts honored?\n / Performance Tests \\ ← Not slower than before?\n / Data Validation Tests \\ ← Data migrated correctly?\n / Unit Tests \\ ← New code works?" }, { "title": "Parity Testing Framework", "body": "For EVERY migrated feature:\n\nfeature: \"\"\ntest_type: \"api_parity | ui_parity | data_parity\"\nmethod: \"shadow traffic | replay | parallel run\"\nsample_size: 0\nmatch_rate: \"0%\" # Target: 99.9%+\nmismatches_investigated: 0\nmismatches_accepted: 0 # Known intentional differences\nmismatches_bugs: 0\nsign_off: false\n\nShadow traffic — copy production requests to new system, compare responses (don't serve new responses to users yet)." }, { "title": "Performance Regression Rules", "body": "P95 latency must not increase >10% vs legacy\nThroughput must meet or exceed legacy under same load\nDatabase query count must not increase per request\nMemory usage must not increase >20%\nIf ANY metric regresses → investigate before proceeding" }, { "title": "Modernization Team Structure", "body": "RoleResponsibilityWhen NeededModernization LeadStrategy, sequencing, blockersFull-timeLegacy ExpertKnows where the bodies are buriedPart-time, on-callNew Platform EngineerBuilds target architectureFull-timeData EngineerMigration, sync, validationPhase-dependentQA/Test EngineerParity testing, automationFull-timeDevOps/PlatformCI/CD, infrastructurePart-timeProduct OwnerBusiness priority, acceptancePart-time" }, { "title": "Knowledge Mining from Legacy", "body": "The most dangerous part of modernization is losing undocumented business rules.\n\nCode archaeology — git blame, find oldest unchanged code, understand why\nInterview stakeholders — \"What would break if we changed X?\"\nProduction log analysis — what edge cases actually occur?\nError handling review — each catch block is a documented business rule\nTest suite review — tests describe expected behavior\nConfiguration review — magic numbers, feature flags, overrides" }, { "title": "Communication Plan", "body": "AudienceFrequencyContentExecutive sponsorBi-weeklyProgress, risks, budget, timelineEngineering teamWeeklySprint goals, technical decisions, blockersDependent teamsMonthlyUpcoming changes, migration dates, API changesEnd usersPer migrationWhat's changing, when, how it affects them" }, { "title": "Top 10 Modernization Risks (Pre-Built)", "body": "#RiskLikelihoodImpactMitigation1Undocumented business rules lostHighCriticalCode archaeology + stakeholder interviews + parity tests2Timeline underestimationVery HighHigh2x initial estimate, phase-gated checkpoints3Data migration corruptionMediumCriticalChecksums, parallel runs, rollback plans4Feature parity gapsHighHighShadow traffic testing, user acceptance testing5Team knowledge loss (people leave)MediumHighDocument everything, pair programming, knowledge sharing6Legacy system changes during migrationHighMediumFeature freeze or dual-write contract7Performance regressionMediumHighLoad testing at every phase, performance budgets8Scope creep (improve while migrating)Very HighMediumStrict \"migrate, don't improve\" rule for Phase 19Integration failuresMediumHighContract testing, circuit breakers, fallback routing10Stakeholder fatigueHighMediumQuick wins early, visible progress dashboard" }, { "title": "Kill Criteria", "body": "Stop the modernization if:\n\nBudget exceeds 2x initial estimate with <50% complete\nKey business rules can't be verified after migration\nTeam attrition >30% during project\nLegacy system stability degrades due to migration work\nBusiness context changes (M&A, pivot, sunset)\n\nIf kill criteria triggered: Stabilize what's done, document learnings, reassess in 6 months." }, { "title": "Language/Framework Migration Patterns", "body": "Java → Modern Java (8→17+)\n\nRecords, sealed classes, pattern matching\nVirtual threads (Project Loom) for thread-per-request\nMigrate build: Maven→Gradle or update Maven plugins\nSpring Boot 2→3: javax→jakarta namespace\n\nPython 2→3\n\nUse 2to3 tool for automated conversion\nFix: print(), division, unicode, dict methods\nUpgrade dependencies (check py3 compat)\n\njQuery→React/Vue\n\nExtract components from page sections\nState management replaces DOM manipulation\nEvent handlers become component methods\nAjax calls become API service layer\n\nMonolith→Microservices\n\nStrangler fig (see Phase 3)\nStart with read models (reporting, search)\nExtract stateless services first\nShared database → database-per-service last\n\nOn-Prem→Cloud\n\nRehost first (lift & shift)\nThen replatform (managed services)\nThen re-architect (cloud-native patterns)\nNever skip steps — each proves value" }, { "title": "COBOL/Mainframe Modernization", "body": "API wrapping — expose CICS/IMS transactions as REST APIs\nScreen scraping — automate 3270 terminal interactions\nGradual extraction — one transaction at a time\nData replication — DB2/VSAM → PostgreSQL/cloud DB\nRule extraction — COBOL paragraphs → business rule engine\nNever rewrite all at once — decades of business logic = decades of edge cases" }, { "title": "Microservices Anti-Patterns to Avoid", "body": "Anti-PatternSymptomFixDistributed monolithServices must deploy togetherIdentify and break couplingShared databaseMultiple services write same tablesDatabase-per-serviceSynchronous chainsA calls B calls C calls DAsync events, choreographyNano-servicesHundreds of tiny servicesMerge related servicesShared libraries for business logicLibrary update breaks consumersDuplicate code > shared couplingNo API versioningBreaking changes cascadeSemantic versioning, deprecation policy" }, { "title": "Modernization Health Dashboard", "body": "project: \"\"\nassessment_date: \"\"\noverall_health: \"green | yellow | red\"\n\nprogress:\n modules_total: 0\n modules_migrated: 0\n modules_in_progress: 0\n percent_complete: \"0%\"\n \nvelocity:\n modules_per_sprint: 0\n estimated_completion: \"\"\n on_track: true\n\nquality:\n parity_test_pass_rate: \"0%\"\n production_incidents_from_migration: 0\n rollbacks: 0\n \nrisk:\n open_risks: 0\n p0_risks: 0\n blocked_items: 0\n\ncost:\n budget_total: \"$0\"\n budget_spent: \"$0\"\n budget_remaining: \"$0\"\n burn_rate_monthly: \"$0\"" }, { "title": "100-Point Modernization Quality Rubric", "body": "DimensionWeightScore (0-10)WeightedStrategy clarity15%Risk management15%Testing rigor15%Data integrity15%Architecture quality10%Team capability10%Stakeholder alignment10%Documentation10%Total100%/100\n\n90-100: Exemplary — reference project\n70-89: Strong — minor improvements\n50-69: Adequate — address gaps\nBelow 50: At risk — pause and reassess" }, { "title": "Weekly Status Template", "body": "## Modernization Status — Week of [DATE]\n\n### Progress\n- Modules migrated this week: [N]\n- Total migrated: [N]/[TOTAL] ([X]%)\n- On track for [TARGET DATE]: [Yes/No]\n\n### Completed\n- [What shipped this week]\n\n### In Progress\n- [What's being worked on]\n\n### Blockers\n- [What's stuck and what's needed]\n\n### Risks\n- [New or changed risks]\n\n### Next Week\n- [Plan for next sprint]" }, { "title": "\"We need to modernize but can't stop adding features\"", "body": "Strangler fig — modernize around new features\nFeature freeze on legacy module ONLY when that module is being migrated\nNew features build in new stack from day 1" }, { "title": "\"We don't know what the system does\"", "body": "Start with observability: instrument logging, tracing, metrics\nRun for 2-4 weeks to understand actual usage patterns\nCode coverage analysis shows what code is actually executed\nInterview longest-tenured team members" }, { "title": "\"Multiple systems need modernizing simultaneously\"", "body": "Sequence by dependency order — downstream first\nShared services (auth, data) get modernized once, reused\nNever parallelize more than 2 modernization streams" }, { "title": "\"The original developers are gone\"", "body": "Treat code as the documentation\nInvest 2-4 weeks in code archaeology before any migration work\nPair new developers with business stakeholders\nWrite tests for existing behavior before changing anything" }, { "title": "\"We're being acquired / merging systems\"", "body": "Map overlapping functionality first\nPick \"winner\" system per domain — don't merge codebases\nAPI integration layer between systems\n18-month realistic timeline for full consolidation" }, { "title": "\"Compliance requires the old system\"", "body": "Maintain compliance evidence chain during migration\nDual-audit period with both systems\nGet compliance team involved in migration planning from Day 1\nDocument control mapping: old control → new implementation" }, { "title": "Natural Language Commands", "body": "CommandAction\"Assess this system for modernization\"Run full Technical Debt Inventory\"Which modernization strategy should we use?\"Walk through Strategy Decision Tree\"Plan a strangler fig migration\"Generate Strangler Facade YAML + sequence\"Decompose this monolith\"Domain discovery + Bounded Context mapping\"Migrate this database\"Data Quality Gates + migration strategy\"Check cloud readiness\"Run Cloud Readiness Assessment\"Create a migration testing plan\"Build Testing Pyramid with parity tests\"What are the risks?\"Generate Top 10 risk register\"How do we migrate from [X] to [Y]?\"Pattern-specific playbook\"Status update for modernization\"Generate Weekly Status Template\"Score this modernization project\"Run 100-Point Quality Rubric\"Should we kill this modernization?\"Evaluate Kill Criteria" } ], "body": "Legacy System Modernization Engine\n\nComplete methodology for assessing, planning, and executing legacy system modernization — from monolith decomposition to cloud migration. Works for any tech stack, any scale.\n\nPhase 1: System Assessment\nModernization Brief\nsystem_name: \"[Name]\"\nage_years: 0\nprimary_language: \"\"\nframework: \"\"\ndatabase: \"\"\ndeployment: \"on-prem | VM | container | serverless\"\nlines_of_code: 0\nteam_size: 0\nmonthly_users: 0\nannual_revenue_supported: \"$0\"\ncompliance_requirements: []\nknown_pain_points: []\nbusiness_driver: \"cost | speed | talent | risk | compliance | scale\"\ntimeline_pressure: \"low | medium | high | critical\"\nbudget_range: \"$0-$0\"\nsponsor: \"\"\n\nTechnical Debt Inventory\n\nScore each dimension 1-5 (1=critical, 5=healthy):\n\nDimension\tScore\tEvidence\nCode quality — test coverage, complexity, duplication\t\t\nArchitecture — coupling, modularity, clear boundaries\t\t\nInfrastructure — deployment automation, monitoring, scaling\t\t\nDependencies — outdated libraries, EOL frameworks, security vulns\t\t\nData — schema quality, migration history, backup/recovery\t\t\nDocumentation — accuracy, coverage, onboarding effectiveness\t\t\nOperations — deployment frequency, MTTR, incident rate\t\t\nSecurity — auth patterns, encryption, audit trail, compliance gaps\t\t\nDeveloper experience — build time, local setup, debugging tools\t\t\nBusiness logic clarity — documented rules, test coverage of logic\t\t\n\nTotal: /50\n\n40-50: Healthy — incremental improvement\n30-39: Aging — targeted modernization\n20-29: Legacy — systematic modernization needed\n10-19: Critical — modernize or replace\nDependency Risk Matrix\n\nFor each major dependency:\n\ndependency: \"\"\ncurrent_version: \"\"\nlatest_version: \"\"\neol_date: \"\" # End of life\nsecurity_vulns: 0 # Known CVEs\nupgrade_difficulty: \"trivial | moderate | hard | rewrite\"\nbusiness_risk: \"low | medium | high | critical\"\nalternatives: []\n\n\nPriority rules:\n\nEOL within 12 months → P0\nKnown unpatched CVEs → P0\n3+ major versions behind → P1\nNo active maintainer → P1\nEverything else → P2\nPhase 2: Strategy Selection\nModernization Strategy Decision Matrix\nStrategy\tWhen to Use\tRisk\tCost\tSpeed\tDisruption\nRehost (lift & shift)\tDatacenter exit, minimal change\tLow\tLow\tFast\tLow\nReplatform (lift & optimize)\tCloud benefits without rewrite\tLow-Med\tMedium\tMedium\tLow-Med\nRefactor (restructure)\tGood code, bad architecture\tMedium\tMedium\tMedium\tMedium\nRe-architect (rebuild patterns)\tMonolith→services, new patterns\tHigh\tHigh\tSlow\tHigh\nRebuild (rewrite)\tSmall system, clear requirements\tVery High\tVery High\tVery Slow\tVery High\nReplace (buy/SaaS)\tCommodity functionality\tMedium\tVariable\tFast\tHigh\nRetire\tNo longer needed\tNone\tNegative\tInstant\tLow\nRetain (do nothing)\tWorking fine, other priorities\tNone\tOngoing\tN/A\tNone\nStrategy Selection Decision Tree\nIs the system still needed?\n├─ No → RETIRE\n├─ Yes → Is it a commodity (CRM, email, etc.)?\n│ ├─ Yes → REPLACE (buy SaaS)\n│ └─ No → Is the code maintainable?\n│ ├─ Yes → Is the architecture the problem?\n│ │ ├─ Yes → RE-ARCHITECT (strangler fig)\n│ │ └─ No → Is the infrastructure the problem?\n│ │ ├─ Yes → REPLATFORM\n│ │ └─ No → REFACTOR incrementally\n│ └─ No → Is the system small (<50K LOC)?\n│ ├─ Yes → Can requirements be clearly defined?\n│ │ ├─ Yes → REBUILD\n│ │ └─ No → REFACTOR + RE-ARCHITECT\n│ └─ No → STRANGLER FIG (never big-bang rewrite)\n\nThe Big Rewrite Anti-Pattern\n\nNEVER do a full rewrite of a large system. It fails 70%+ of the time because:\n\nThe old system keeps getting features — moving target\nHidden business rules only exist in code — they get lost\nTimeline always 2-3x longer than estimated\nTwo systems to maintain during transition\nTeam burns out before completion\n\nAlways use Strangler Fig instead. Replace piece by piece.\n\nPhase 3: Strangler Fig Pattern\nHow It Works\nIdentify a boundary — a feature, page, or API endpoint\nBuild the replacement — new stack, new patterns\nRoute traffic — proxy/facade sends requests to new or old\nVerify parity — same behavior, same data\nCut over — remove the proxy, retire the old code\nRepeat — next boundary\nStrangler Facade YAML\nfacade_name: \"[API Gateway / Reverse Proxy / BFF]\"\nrouting_rules:\n - path: \"/api/users/*\"\n target: \"new-service\"\n status: \"migrated\"\n migrated_date: \"2025-01-15\"\n - path: \"/api/orders/*\"\n target: \"legacy\"\n status: \"planned\"\n target_date: \"2025-Q2\"\n - path: \"/api/reports/*\"\n target: \"legacy\"\n status: \"not-planned\"\n notes: \"Low priority, rarely used\"\n\nMigration Sequence Rules\nStart with the easiest, most isolated module — build confidence\nThen the highest-value business capability — prove ROI early\nLeave the hardest, most coupled parts for last — team learns patterns first\nNever migrate auth/identity early — it touches everything\nMigrate data access layer before business logic — clean data = clean migration\nAlways keep the old system as fallback until new is proven\nDual-Write / Data Sync Patterns\nPattern\tWhen\tComplexity\tRisk\nDual write\tBoth systems write simultaneously\tHigh\tData inconsistency\nCDC (Change Data Capture)\tStream changes from old→new DB\tMedium\tLag, ordering\nETL batch sync\tPeriodic bulk sync\tLow\tStale data\nEvent sourcing bridge\tEvents from old, replay in new\tHigh\tSchema mapping\nRead from new, write to old\tTransition period\tMedium\tRouting complexity\n\nGolden rule: Pick ONE source of truth. Never let both systems own the same data simultaneously.\n\nPhase 4: Monolith Decomposition\nDomain Discovery\n\nBefore splitting a monolith, identify bounded contexts:\n\nEvent Storming (preferred) — sticky notes for domain events, commands, aggregates\nCode analysis — find clusters of related classes/tables\nTeam analysis — which teams own which features?\nData coupling analysis — which tables are joined together?\nBounded Context YAML\ncontext_name: \"\"\ndescription: \"\"\nteam: \"\"\nentities: []\ncommands: []\nevents_published: []\nevents_consumed: []\ndatabase_tables: []\nexternal_integrations: []\ncoupling_score: 0 # 0=independent, 10=deeply coupled\nextraction_difficulty: \"easy | moderate | hard | very-hard\"\nbusiness_value: \"low | medium | high | critical\"\n\nExtraction Priority Matrix\n\nPlot contexts on: Business Value (Y) × Extraction Difficulty (X)\n\n\tEasy\tModerate\tHard\nHigh value\t🟢 Do first\t🟡 Do second\t🟠 Plan carefully\nMedium value\t🟢 Quick win\t🟡 Evaluate ROI\t🔴 Probably not worth it\nLow value\t🟡 If easy, why not\t🔴 Skip\t🔴 Definitely skip\nService Extraction Checklist\n\nFor each service being extracted:\n\n Bounded context clearly defined\n API contract designed (OpenAPI spec)\n Database separated (no shared tables)\n Authentication/authorization integrated\n Event publishing for cross-service communication\n Circuit breaker for calls back to monolith\n Monitoring and alerting configured\n Deployment pipeline independent\n Feature flag for traffic routing\n Rollback plan documented\n Performance baseline captured (before/after)\n Data migration script tested\n Integration tests with monolith passing\n Runbook for on-call written\nPhase 5: Database Modernization\nDatabase Migration Strategies\nStrategy\tDescription\tDowntime\tRisk\nParallel run\tNew DB alongside old, sync both\tZero\tHigh complexity\nBlue-green\tFull copy, switch DNS\tMinutes\tMedium\nRolling\tMigrate table by table\tZero per table\tMedium\nBig bang\tStop, migrate, start\tHours\tHigh\nSchema Evolution Rules\nAlways additive — add columns/tables, never remove in the same release\nTwo-phase removal — Release 1: stop writing. Release 2: drop column (after backfill verified)\nDefault values always — every new column gets a default\nBackward compatible — old code must work with new schema during rollout\nIndex concurrently — never lock production tables\nTest with production-scale data — 100 rows ≠ 100M rows\nData Quality Gates\n\nBefore migrating data:\n\ntable: \"\"\nrow_count_source: 0\nrow_count_target: 0\ncount_match: false\nchecksum_match: false\nnull_analysis: \"pass | fail\"\nreferential_integrity: \"pass | fail\"\nbusiness_rule_validation: \"pass | fail\"\nsample_manual_review: \"pass | fail\"\nperformance_benchmark: \"pass | fail\"\nrollback_tested: false\n\n\nRule: All gates must pass before cutover. No exceptions.\n\nPhase 6: Cloud Migration\nCloud Readiness Assessment\n\nScore each workload:\n\nFactor\tScore (1-5)\tNotes\nStateless design\t\t\nConfiguration externalized\t\t\nLogging to stdout\t\t\nHealth check endpoint\t\t\nGraceful shutdown\t\t\nHorizontal scalability\t\t\nSecret management\t\t\n12-factor compliance\t\t\n\n35-40: Cloud-native ready 25-34: Minor modifications needed 15-24: Significant refactoring 8-14: Major redesign required\n\nCloud Migration Checklist\n Network architecture designed (VPC, subnets, security groups)\n Identity and access management configured\n Data residency requirements verified\n Compliance mapping (cloud controls ↔ requirements)\n Cost estimation completed (TCO comparison)\n Disaster recovery plan updated\n Monitoring and alerting migrated\n DNS and certificate management planned\n CDN configuration\n Load testing in cloud environment\n Security scanning pipeline\n Backup and restore verified\n Runbooks updated for cloud operations\n Team trained on cloud platform\n Vendor lock-in assessment\nCost Optimization from Day 1\nRight-size instances — start small, scale up with data\nReserved/committed use — only after 3 months of usage data\nSpot/preemptible — for batch jobs, CI/CD, dev/test\nAuto-scaling — scale down at night, weekends\nStorage tiers — hot/warm/cold/archive based on access patterns\nTag everything — cost allocation by team, service, environment\nMonthly review — unused resources, oversized instances\nPhase 7: API Modernization\nAPI Wrapping Pattern\n\nFor legacy systems without APIs:\n\nScreen scraping adapter — parse HTML/mainframe screens\nDatabase tap — read directly from legacy DB (read-only!)\nFile-based integration — watch folders, parse files\nMessage queue bridge — legacy writes to queue, new reads\nRPC wrapper — expose existing functions via REST/gRPC\nAPI Contract-First Migration\nendpoint: \"/api/v2/orders\"\nlegacy_source: \"stored_procedure: sp_GetOrders\"\nnew_implementation: \"orders-service\"\nmigration_status: \"legacy | dual-run | new-only\"\ncontract_changes:\n - field: \"order_date\"\n old_format: \"MM/DD/YYYY string\"\n new_format: \"ISO 8601\"\n adapter: \"date_format_adapter\"\n - field: \"status\"\n old_values: [\"A\", \"C\", \"P\"]\n new_values: [\"active\", \"completed\", \"pending\"]\n adapter: \"status_code_mapper\"\nparity_tests: 47\nparity_passing: 47\n\nPhase 8: Testing Strategy\nMigration Testing Pyramid\n / Smoke Tests \\ ← Whole system alive?\n / Parity Tests \\ ← Same behavior old vs new?\n / Integration Tests \\ ← Services work together?\n / Contract Tests \\ ← API contracts honored?\n / Performance Tests \\ ← Not slower than before?\n / Data Validation Tests \\ ← Data migrated correctly?\n / Unit Tests \\ ← New code works?\n\nParity Testing Framework\n\nFor EVERY migrated feature:\n\nfeature: \"\"\ntest_type: \"api_parity | ui_parity | data_parity\"\nmethod: \"shadow traffic | replay | parallel run\"\nsample_size: 0\nmatch_rate: \"0%\" # Target: 99.9%+\nmismatches_investigated: 0\nmismatches_accepted: 0 # Known intentional differences\nmismatches_bugs: 0\nsign_off: false\n\n\nShadow traffic — copy production requests to new system, compare responses (don't serve new responses to users yet).\n\nPerformance Regression Rules\nP95 latency must not increase >10% vs legacy\nThroughput must meet or exceed legacy under same load\nDatabase query count must not increase per request\nMemory usage must not increase >20%\nIf ANY metric regresses → investigate before proceeding\nPhase 9: Team & Process\nModernization Team Structure\nRole\tResponsibility\tWhen Needed\nModernization Lead\tStrategy, sequencing, blockers\tFull-time\nLegacy Expert\tKnows where the bodies are buried\tPart-time, on-call\nNew Platform Engineer\tBuilds target architecture\tFull-time\nData Engineer\tMigration, sync, validation\tPhase-dependent\nQA/Test Engineer\tParity testing, automation\tFull-time\nDevOps/Platform\tCI/CD, infrastructure\tPart-time\nProduct Owner\tBusiness priority, acceptance\tPart-time\nKnowledge Mining from Legacy\n\nThe most dangerous part of modernization is losing undocumented business rules.\n\nCode archaeology — git blame, find oldest unchanged code, understand why\nInterview stakeholders — \"What would break if we changed X?\"\nProduction log analysis — what edge cases actually occur?\nError handling review — each catch block is a documented business rule\nTest suite review — tests describe expected behavior\nConfiguration review — magic numbers, feature flags, overrides\nCommunication Plan\nAudience\tFrequency\tContent\nExecutive sponsor\tBi-weekly\tProgress, risks, budget, timeline\nEngineering team\tWeekly\tSprint goals, technical decisions, blockers\nDependent teams\tMonthly\tUpcoming changes, migration dates, API changes\nEnd users\tPer migration\tWhat's changing, when, how it affects them\nPhase 10: Risk Management\nTop 10 Modernization Risks (Pre-Built)\n#\tRisk\tLikelihood\tImpact\tMitigation\n1\tUndocumented business rules lost\tHigh\tCritical\tCode archaeology + stakeholder interviews + parity tests\n2\tTimeline underestimation\tVery High\tHigh\t2x initial estimate, phase-gated checkpoints\n3\tData migration corruption\tMedium\tCritical\tChecksums, parallel runs, rollback plans\n4\tFeature parity gaps\tHigh\tHigh\tShadow traffic testing, user acceptance testing\n5\tTeam knowledge loss (people leave)\tMedium\tHigh\tDocument everything, pair programming, knowledge sharing\n6\tLegacy system changes during migration\tHigh\tMedium\tFeature freeze or dual-write contract\n7\tPerformance regression\tMedium\tHigh\tLoad testing at every phase, performance budgets\n8\tScope creep (improve while migrating)\tVery High\tMedium\tStrict \"migrate, don't improve\" rule for Phase 1\n9\tIntegration failures\tMedium\tHigh\tContract testing, circuit breakers, fallback routing\n10\tStakeholder fatigue\tHigh\tMedium\tQuick wins early, visible progress dashboard\nKill Criteria\n\nStop the modernization if:\n\nBudget exceeds 2x initial estimate with <50% complete\nKey business rules can't be verified after migration\nTeam attrition >30% during project\nLegacy system stability degrades due to migration work\nBusiness context changes (M&A, pivot, sunset)\n\nIf kill criteria triggered: Stabilize what's done, document learnings, reassess in 6 months.\n\nPhase 11: Patterns & Playbooks\nLanguage/Framework Migration Patterns\n\nJava → Modern Java (8→17+)\n\nRecords, sealed classes, pattern matching\nVirtual threads (Project Loom) for thread-per-request\nMigrate build: Maven→Gradle or update Maven plugins\nSpring Boot 2→3: javax→jakarta namespace\n\nPython 2→3\n\nUse 2to3 tool for automated conversion\nFix: print(), division, unicode, dict methods\nUpgrade dependencies (check py3 compat)\n\njQuery→React/Vue\n\nExtract components from page sections\nState management replaces DOM manipulation\nEvent handlers become component methods\nAjax calls become API service layer\n\nMonolith→Microservices\n\nStrangler fig (see Phase 3)\nStart with read models (reporting, search)\nExtract stateless services first\nShared database → database-per-service last\n\nOn-Prem→Cloud\n\nRehost first (lift & shift)\nThen replatform (managed services)\nThen re-architect (cloud-native patterns)\nNever skip steps — each proves value\nCOBOL/Mainframe Modernization\nAPI wrapping — expose CICS/IMS transactions as REST APIs\nScreen scraping — automate 3270 terminal interactions\nGradual extraction — one transaction at a time\nData replication — DB2/VSAM → PostgreSQL/cloud DB\nRule extraction — COBOL paragraphs → business rule engine\nNever rewrite all at once — decades of business logic = decades of edge cases\nMicroservices Anti-Patterns to Avoid\nAnti-Pattern\tSymptom\tFix\nDistributed monolith\tServices must deploy together\tIdentify and break coupling\nShared database\tMultiple services write same tables\tDatabase-per-service\nSynchronous chains\tA calls B calls C calls D\tAsync events, choreography\nNano-services\tHundreds of tiny services\tMerge related services\nShared libraries for business logic\tLibrary update breaks consumers\tDuplicate code > shared coupling\nNo API versioning\tBreaking changes cascade\tSemantic versioning, deprecation policy\nPhase 12: Metrics & Reporting\nModernization Health Dashboard\nproject: \"\"\nassessment_date: \"\"\noverall_health: \"green | yellow | red\"\n\nprogress:\n modules_total: 0\n modules_migrated: 0\n modules_in_progress: 0\n percent_complete: \"0%\"\n \nvelocity:\n modules_per_sprint: 0\n estimated_completion: \"\"\n on_track: true\n\nquality:\n parity_test_pass_rate: \"0%\"\n production_incidents_from_migration: 0\n rollbacks: 0\n \nrisk:\n open_risks: 0\n p0_risks: 0\n blocked_items: 0\n\ncost:\n budget_total: \"$0\"\n budget_spent: \"$0\"\n budget_remaining: \"$0\"\n burn_rate_monthly: \"$0\"\n\n100-Point Modernization Quality Rubric\nDimension\tWeight\tScore (0-10)\tWeighted\nStrategy clarity\t15%\t\t\nRisk management\t15%\t\t\nTesting rigor\t15%\t\t\nData integrity\t15%\t\t\nArchitecture quality\t10%\t\t\nTeam capability\t10%\t\t\nStakeholder alignment\t10%\t\t\nDocumentation\t10%\t\t\nTotal\t100%\t\t/100\n\n90-100: Exemplary — reference project 70-89: Strong — minor improvements 50-69: Adequate — address gaps Below 50: At risk — pause and reassess\n\nWeekly Status Template\n## Modernization Status — Week of [DATE]\n\n### Progress\n- Modules migrated this week: [N]\n- Total migrated: [N]/[TOTAL] ([X]%)\n- On track for [TARGET DATE]: [Yes/No]\n\n### Completed\n- [What shipped this week]\n\n### In Progress\n- [What's being worked on]\n\n### Blockers\n- [What's stuck and what's needed]\n\n### Risks\n- [New or changed risks]\n\n### Next Week\n- [Plan for next sprint]\n\nEdge Cases\n\"We need to modernize but can't stop adding features\"\nStrangler fig — modernize around new features\nFeature freeze on legacy module ONLY when that module is being migrated\nNew features build in new stack from day 1\n\"We don't know what the system does\"\nStart with observability: instrument logging, tracing, metrics\nRun for 2-4 weeks to understand actual usage patterns\nCode coverage analysis shows what code is actually executed\nInterview longest-tenured team members\n\"Multiple systems need modernizing simultaneously\"\nSequence by dependency order — downstream first\nShared services (auth, data) get modernized once, reused\nNever parallelize more than 2 modernization streams\n\"The original developers are gone\"\nTreat code as the documentation\nInvest 2-4 weeks in code archaeology before any migration work\nPair new developers with business stakeholders\nWrite tests for existing behavior before changing anything\n\"We're being acquired / merging systems\"\nMap overlapping functionality first\nPick \"winner\" system per domain — don't merge codebases\nAPI integration layer between systems\n18-month realistic timeline for full consolidation\n\"Compliance requires the old system\"\nMaintain compliance evidence chain during migration\nDual-audit period with both systems\nGet compliance team involved in migration planning from Day 1\nDocument control mapping: old control → new implementation\nNatural Language Commands\nCommand\tAction\n\"Assess this system for modernization\"\tRun full Technical Debt Inventory\n\"Which modernization strategy should we use?\"\tWalk through Strategy Decision Tree\n\"Plan a strangler fig migration\"\tGenerate Strangler Facade YAML + sequence\n\"Decompose this monolith\"\tDomain discovery + Bounded Context mapping\n\"Migrate this database\"\tData Quality Gates + migration strategy\n\"Check cloud readiness\"\tRun Cloud Readiness Assessment\n\"Create a migration testing plan\"\tBuild Testing Pyramid with parity tests\n\"What are the risks?\"\tGenerate Top 10 risk register\n\"How do we migrate from [X] to [Y]?\"\tPattern-specific playbook\n\"Status update for modernization\"\tGenerate Weekly Status Template\n\"Score this modernization project\"\tRun 100-Point Quality Rubric\n\"Should we kill this modernization?\"\tEvaluate Kill Criteria" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/1kalin/afrexai-legacy-modernization", "publisherUrl": "https://clawhub.ai/1kalin/afrexai-legacy-modernization", "owner": "1kalin", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization", "downloadUrl": "https://openagent3.xyz/downloads/afrexai-legacy-modernization", "agentUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-legacy-modernization/agent.md" } }