Accommodation Migration Ownership Status

Canonical accommodation migration owner

Canonical accommodation migration owner is not fully transferred yet.

Current practical owner:

• services/svc-tenders/migrations

Current extracted runtime state:

• services/svc-accommodations is the active route/runtime host
• but it does not yet own an accommodation-specific migration tree

Accommodation-related migrations currently in svc-tenders

Accommodation-dominant migrations

These are the strongest accommodation-specific candidates for future transfer:

• services/svc-tenders/migrations/0041_accommodation_write_model.sql
• services/svc-tenders/migrations/0045_change_accommodation_id_to_text.sql
• services/svc-tenders/migrations/0046_seed_accommodation_data.sql

Legacy compatibility residue

These are older shared vacancy/accommodation or accommodation-catalog residue:

• services/svc-tenders/migrations/0005_vacancies_accommodations.sql
• services/svc-tenders/migrations/0006_accommodations_detail_payload.sql

Mixed migrations

These remain mixed enough that they should not be casually claimed as accommodation-only:

• services/svc-tenders/migrations/0042_vacancy_accommodation_context.sql
• services/svc-tenders/migrations/0043_vacancy_accommodation_declaration_details.sql
• services/svc-tenders/migrations/0044_add_details_json_to_views.sql

What remains in the old host

Migration-related accommodation residue that still remains tied to svc-tenders:

• the only current migration invocation path for accommodation schema changes
• the legacy compatibility table history for public catalog reads
• mixed vacancy/accommodation schema changes that do not yet have a clean service owner split

What can be deleted now

Nothing migration-related should be deleted in Sprint 64.

Reason:

• migration ownership is still mixed
• there is no canonical services/svc-accommodations/migrations handoff yet
• deleting migration files now would blur ownership rather than clarify it

What this means for legacy-host deletion

Migration ownership does not block legacy route-host retirement by itself.

Why:

• the live accommodation cutover already runs against the same shared database truth
• retiring the old route host is different from deleting migration history
• the legacy host can be removed while migration residue stays temporarily in svc-tenders

What migration ownership still blocks:

• claiming accommodation extraction is fully complete
• deleting accommodation-related migration residue from svc-tenders
• declaring svc-accommodations the canonical migration owner yet

Prerequisites before migration deletion or transfer

Before any migration transfer/deletion:

1. create a canonical accommodation migration home under svc-accommodations or another explicitly chosen owner
2. classify which files stay mixed with vacancy and which are truly accommodation-only
3. decide whether legacy 0005 / 0006 stay as historical shared residue or move into a broader WorkStay migration story
4. update operator migration runbooks so invocation is not ambiguous

Notes

• The route/runtime cutover is ahead of the migration-ownership split.
• That asymmetry is acceptable for host retirement planning as long as it is stated explicitly.
• The right next step is route-host retirement first, then migration ownership cleanup, not the other way around.