mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-19 07:28:43 +00:00
Paul Delannoy
f7e8aaa2d8
* Enhance Oracle-to-PostgreSQL migration skills and documentation
- Update migration agent guidelines to prioritize extension tool usage for code migration.
- Refine migration phases with detailed steps for pre-migration review and schema migration.
- Add new reviewing skill references for PostgreSQL materialized view refresh and UNION ALL planner risks.
- Ensure consistency in collation handling and testing strategies across skills.
* - Review migration phases to ensure correct order of execution
- Add exit criteria to each migration phase
- Remove invocation of `ms-ossdata.vscode-pgsql` extension due to dependency on VSCode
- Update README.md to reflect changes in migration phases and exit criteria
- Update broken reference to custom agent in plugin.json
* Enhance downstream migration skills and following custom agent improvements
- Added new skill for migrating .NET data access code from Oracle to PostgreSQL.
- Updated README to include new migration skill.
- Improved existing skills with clearer file naming conventions and migration actions.
- Added reference documents for handling Oracle-specific functions and pagination.
- Created detailed guides for NVL, DECODE, ROWNUM, SYSDATE, and DUAL replacements.
* Clarify PostgreSQL schema immutability and stored procedure migration risks
* Update target schema path in migration documentation for clarity
* fix(skills): clarify Phase 3-only scope for Oracle test skills
Both Oracle test skills were ambiguously worded in ways that could
cause a model to invoke them during Phase 6 (PostgreSQL test migration)
instead of using them exclusively in Phase 3.
Key changes:
- Rewrite descriptions to explicitly state Phase 3-only usage and
warn against invoking during Phase 6
- Replace "scaffold for Oracle first" with "Oracle only" to remove
the false implication of a second PostgreSQL scaffolding step
- Replace "Tests validate behavior consistency when running against
Oracle or PostgreSQL" with clear Oracle-only framing
- Rename "DB-agnostic assertions" → "Assertion portability" and
explain the why (survive Phase 6 migration without rewrites)
- Fix datetime bullet in integration tests skill to use generic
Oracle column precision language instead of PostgreSQL type syntax
- Name Oracle NuGet package explicitly (Oracle.ManagedDataAccess.Core)
* feat(oracle-to-postgres): gate Phase 1 on DDL presence; add DDL scan to Phase 2 risk analysis
- Phase 1 success criteria now requires Oracle DDL artifacts to be
confirmed present at the recorded location before proceeding.
If missing, the agent stops and prompts the user to provide them.
- Phase 2 risk analysis now explicitly scans DDL/Oracle/{ProjectName}/
as supplemental context, summarising procedure complexity indicators
(dynamic SQL, DBMS_* / UTL_* references, autonomous transactions,
pipelined functions, BULK COLLECT/FORALL, REF CURSOR, TYPE bodies)
rather than ingesting DDL files wholesale. This ensures schema-level
migration risk is captured even when it isn't visible in application
code alone.
* - Merge in latest 'main' changes
- Update custom agent plugin (eg resolve conflict and add new skill)
- Validate skills
- Run build
* chore(plugin.json): update version to 1.1.0
* feat(oracle-to-postgres): update version to 1.1.0 for migration expert plugin
* fix: add INOUT to ignore-words-list for PostgreSQL migration
---------
Co-authored-by: TCPrimedPaul <paul.delannoy@tc.gc.ca>
89 lines
3.4 KiB
Markdown
89 lines
3.4 KiB
Markdown
---
|
|
name: creating-oracle-to-postgres-master-migration-plan
|
|
description: 'Discovers all projects in a .NET solution, classifies each for Oracle-to-PostgreSQL migration eligibility, and produces a persistent master migration plan. Use when starting a multi-project Oracle-to-PostgreSQL migration, creating a migration inventory, or assessing which .NET projects contain Oracle dependencies.'
|
|
---
|
|
|
|
# Creating an Oracle-to-PostgreSQL Master Migration Plan
|
|
|
|
Analyze a .NET solution, classify every project for Oracle→PostgreSQL migration eligibility, and write a structured plan that downstream agents and skills can parse.
|
|
|
|
## Workflow
|
|
|
|
```
|
|
Progress:
|
|
- [ ] Step 1: Discover projects in the solution
|
|
- [ ] Step 2: Classify each project
|
|
- [ ] Step 3: Confirm with user
|
|
- [ ] Step 4: Write the plan file
|
|
```
|
|
|
|
**Step 1: Discover projects**
|
|
|
|
Find the Solution File (it has a `.sln` or `.slnx` extension) in the workspace root (ask the user if multiple exist). Parse it to extract all `.csproj` project references. For each project, note the name, path, and type (class library, web API, console, test, etc.).
|
|
|
|
**Step 2: Classify each project**
|
|
|
|
Scan every non-test project for Oracle indicators:
|
|
|
|
- NuGet references: `Oracle.ManagedDataAccess`, `Oracle.EntityFrameworkCore` (check `.csproj` and `packages.config`)
|
|
- Config entries: Oracle connection strings in `appsettings.json`, `web.config`, `app.config`
|
|
- Code usage: `OracleConnection`, `OracleCommand`, `OracleDataReader`
|
|
- DDL cross-references under `.github/oracle-to-postgres-migration/DDL/Oracle/` (if present)
|
|
|
|
Assign one classification per project:
|
|
|
|
| Classification | Meaning |
|
|
|---|---|
|
|
| **MIGRATE** | Has Oracle interactions requiring conversion |
|
|
| **SKIP** | No Oracle indicators (UI-only, shared utility, etc.) |
|
|
| **ALREADY_MIGRATED** | A `-postgres` or `.Postgres` duplicate exists and appears processed |
|
|
| **TEST_PROJECT** | Test project; handled by the testing workflow |
|
|
|
|
**Step 3: Confirm with user**
|
|
|
|
Present the classified list. Let the user adjust classifications or migration ordering before finalizing.
|
|
|
|
**Step 4: Write the plan file**
|
|
|
|
Save to: `.github/oracle-to-postgres-migration/Reports/MasterMigrationPlan.md`
|
|
|
|
Use this exact template — downstream consumers depend on the structure:
|
|
|
|
````markdown
|
|
# Master Migration Plan
|
|
|
|
**Solution:** {solution file name}
|
|
**Solution Root:** {REPOSITORY_ROOT}
|
|
**Created:** {timestamp}
|
|
**Last Updated:** {timestamp}
|
|
|
|
## DDL Artifacts
|
|
|
|
**Location:** {path to DDL artifacts, e.g., `.github/oracle-to-postgres-migration/DDL/`}
|
|
**External tool used:** {Yes / No} — {If Yes, name the tool (e.g., `ora2pg`) and note that Phase 4 (Schema & DDL Migration) can be skipped; PostgreSQL DDL artifacts already exist.}
|
|
|
|
## Solution Summary
|
|
|
|
| Metric | Count |
|
|
|--------|-------|
|
|
| Total projects in solution | {n} |
|
|
| Projects requiring migration | {n} |
|
|
| Projects already migrated | {n} |
|
|
| Projects skipped (no Oracle usage) | {n} |
|
|
| Test projects (handled separately) | {n} |
|
|
|
|
## Project Inventory
|
|
|
|
| # | Project Name | Path | Classification | Notes |
|
|
|---|---|---|---|---|
|
|
| 1 | {name} | {relative path} | MIGRATE | {notes} |
|
|
| 2 | {name} | {relative path} | SKIP | No Oracle dependencies |
|
|
|
|
## Migration Order
|
|
|
|
1. **{ProjectName}** — {rationale, e.g., "Core data access library; other projects depend on it."}
|
|
2. **{ProjectName}** — {rationale}
|
|
````
|
|
|
|
Order projects so that shared/foundational libraries are migrated before their dependents.
|