Migrate Bootstrap

Plugin check: Run node "${PLUGIN_ROOT}/scripts/check-version.js" — if it outputs a message, show it to the user before proceeding.

Migrate a Traditional Power Pages Site from Bootstrap 3 to Bootstrap 5

Guide the user through migrating a traditional / native Power Pages site from Bootstrap 3 to Bootstrap 5. Follow a systematic approach: verify tooling, acquire and back up the site, assess scope, run the pac pages bootstrap-migrate engine, review the change report, apply the residual fixes the engine can only flag, upload (which auto-enables the runtime flag), verify, and validate.

Core Principles

• Traditional sites only: This skill targets traditional Power Pages sites (Liquid web templates, *.webtemplate.source.html, *.html/.aspx/.ascx, *.css, sitesetting.yml). It does NOT apply to code sites (React/Vue/Angular/Astro) — they are never Bootstrap-3-based. If the target is a code site, stop and tell the user this skill doesn't apply.
• The engine does the bulk; you do the residual: pac pages bootstrap-migrate deterministically applies the well-known class renames. The skill's value is assisting with the hierarchy / CSS changes the engine only logs (see references/bootstrap-v5-manual-fixes.md).
• Non-destructive, with a restore point: The engine writes a new <folder>V5 copy and never edits the source in place. Still, snapshot the source folder (git) before doing anything.
• Assist and flag — never silently rewrite: Residual fixes are Liquid-aware and can break layouts. Apply them with per-category consent; when a case is ambiguous (e.g. Liquid conditionals), flag it for the user instead of guessing.
• Verify the runtime flag flip via pac-log.txt: pac pages upload flips the server-side Bootstrap 5 flag automatically, but flip outcomes are logged and swallowed by the CLI. Never trust the upload exit code alone. The authoritative record is the PAC diagnostic log (pac telemetry status → pac-log.txt); grep it for BootstrapV5UploadPostProcessor. The flip requires an active portal — a website record with no provisioned site logs no portal found and skips.
• Use TaskCreate/TaskUpdate: Create the todo list upfront with all 8 phases before starting work.

Initial request: $ARGUMENTS

Phase 1: Verify Prerequisites

Goal: Ensure PAC CLI is installed, the user is authenticated, the target environment is confirmed, and the required commands are available.

Actions:

1. Create the todo list with all 8 phases (see Progress Tracking).
2. Run pac help to confirm PAC CLI is installed and on PATH. If missing, point the user to https://aka.ms/PowerPlatformCLI (dotnet tool install --global Microsoft.PowerApps.CLI.Tool) and re-verify.

<!-- not-a-gate: data-gathering — free-text environment URL when PAC CLI isn't authenticated; the prompt itself writes nothing -->

3. Run pac auth who. If not authenticated, ask for the environment URL via AskUserQuestion, then pac auth create --environment "<URL>" and re-verify. Capture the environment name, URL, and ID.

<!-- gate: migrate-bootstrap:1.confirm-env | category=consent | cancel-leaves=nothing -->

🚦 Gate (consent · migrate-bootstrap:1.confirm-env): Confirm the target environment before any download, migration, or upload. Running the migration against the wrong environment is destructive, so this confirmation is mandatory.

4. Confirm the target environment with the user (AskUserQuestion: use this environment / choose another via pac org list + pac org select).

5. Probe command availability — both verbs are required:

   pac pages help

   Confirm bootstrap-migrate and upload appear in the verb list. If either is missing (feature not enabled in this CLI build / tenant), stop and tell the user the migration can't proceed until those commands are available.

6. Locate the PAC diagnostic log — capture the path now; you will need it in Phase 7 to verify the flag flip:

   pac telemetry status

   It prints The diagnostic logs can be found at: <…>\logs\pac-log.txt. This is a rolling log across all pac runs and is the authoritative record of the Bootstrap V5 flag flip. Note: pac pages upload writes no per-folder log — pac-log.txt is the only place its post-processor records the flip result. Set PAC_LOG = <that path>.

Output: PAC CLI verified, authenticated session, confirmed environment, bootstrap-migrate and upload confirmed available, PAC_LOG path captured.

Phase 2: Acquire the Site & Back Up

Goal: Get a local copy of the traditional site to migrate, and establish a restore point.

Actions:

2.1 Locate or download the site

• If the user provided a local site folder path (or $ARGUMENTS names one): verify it exists and looks like a downloaded traditional site (contains website.yml and sitesetting.yml). Use it as SITE_FOLDER.

• Otherwise: list available websites and download the chosen one.

  pac pages list

<!-- gate: migrate-bootstrap:2.1.select-site | category=plan | cancel-leaves=nothing -->

🚦 Gate (plan · migrate-bootstrap:2.1.select-site): Choose which website to download when more than one exists. Canceling leaves nothing changed.

Present the websites via AskUserQuestion, then download the selected site:

pac pages download --path "<SITE_FOLDER>" --webSiteId "<WEBSITE_ID>"

Use the downloaded directory as SITE_FOLDER.

Confirm this is a traditional site, not a code site. A code-site project has powerpages.config.json and a framework package.json; a traditional site has website.yml, sitesetting.yml, and *.webtemplate.source.html files. If it's a code site, stop — this skill does not apply.

2.2 Confirm the site is ACTIVATED (not just a website record)

pac pages list shows website records (adx_website). A website record can exist with no provisioned/active Power Pages site (portal) behind it — created by data import/clone, deactivated, or orphaned. The Phase 7 flag flip (SetPortalBootstrapV5Enabled) targets the portal, not the website record, so if no active portal exists the flip silently skips and the live site won't render — and you won't find this out until after uploading unless you check now.

Resolve the site URL from websitebinding.yml (adx_sitename) and probe the final status code (-L follows redirects so a sign-in / canonical-host redirect resolves to its real code):

curl -sL -o /dev/null -w "%{http_code}" "https://<adx_sitename>/"

• 2xx or a redirect that resolves to 2xx/3xx → active portal; proceed. A private or protected site legitimately redirects to sign-in or a canonical host, so a resolved 3xx is active, not a failure.

• 4xx/5xx → inconclusive from the status alone. A private site can return a non-200 without being unactivated, so do not conclude "not activated" from the code alone — fetch the error body (or open the URL in a browser) to look for the unactivated signature:

  curl -sL "https://<adx_sitename>/" | head -c 4000

  If the body shows a Dataverse-connection null-ref (Object reference not set … / CrmOnlineOrganizationService.ToOrganizationService), or the URL fails to render a portal page in the browser, the site is most likely NOT activated. This is the same condition that makes the Phase 7 flag flip log no portal found for website <id> via Power Pages API. A 4xx/5xx without that signature is more likely an auth wall or transient error on an active site — treat as active and note it for the user rather than blocking.

If the site is confirmed not active, stop and tell the user to activate/provision it first (Power Pages admin center, or the /power-pages:activate-site skill). Migrating content into an unactivated website still uploads, but the runtime flag can't flip and the site can't be verified.

2.3 Snapshot the source

Create a restore point before any migration:

cd "<SITE_FOLDER>"
git init -q && git add -A && git commit -q -m "Pre-migration snapshot (Bootstrap 3)"

If the folder is already a git repo, just commit any pending changes so the pre-migration state is captured.

Output: SITE_FOLDER resolved, confirmed traditional, source snapshot committed.

Phase 3: Pre-Migration Assessment

Goal: Set expectations by inventorying Bootstrap-3 usage and flagging risk areas before running the engine.

Actions:

1. Scan the site for Bootstrap-3 markers using Grep over *.html, *.aspx, *.ascx, *.css:

   • Component classes: panel, navbar-header, img-responsive, btn-block, pull-left|pull-right, col-(xs|sm|md|lg)-, glyphicon, label-, page-header, pager, data-toggle|data-dismiss.
   • Count affected files and the rough number of occurrences per category.

2. Flag risk areas:

   • Heavy custom CSS (large .css files with non-Bootstrap selectors) — won't be auto-converted.
   • Liquid-entangled markup ({% ... %} around classes, conditional dropdowns) — needs review.

3. Present a concise scope summary and set expectations:

   "This is an assisted migration. The engine will auto-apply the common Bootstrap 3→5 class renames. Some changes (grid hierarchy, navbar structure, panel/page-header/pager styling) can only be flagged — I'll help apply those in Phase 6. Visual parity isn't guaranteed and you'll want to QA the result."

Output: Scope summary presented; user understands this is assisted, not push-button.

Phase 4: Run the Migration Engine

Goal: Produce the migrated <folder>V5 copy.

Actions:

<!-- gate: migrate-bootstrap:4.run-engine | category=consent | cancel-leaves=nothing -->

🚦 Gate (consent · migrate-bootstrap:4.run-engine): Explicit consent before running pac pages bootstrap-migrate. The engine writes a new <SITE_FOLDER>V5 copy and never edits the source, so canceling leaves nothing changed.

1. Get explicit consent to run the engine (AskUserQuestion: "Run the Bootstrap 5 migration on <SITE_FOLDER>? This creates a new <SITE_FOLDER>V5 copy and does not modify the original.").

2. Run:

   pac pages bootstrap-migrate --path "<SITE_FOLDER>"

3. Confirm the engine produced <SITE_FOLDER>V5 containing:

   • Rewritten *.html / *.js / *.aspx / *.ascx / *.css files
   • Swapped bootstrap.min.css (Bootstrap 5)
   • Updated sitesetting.yml with a Site/BootstrapV5Enabled record
   • logs.txt and per-file *-diff.json

   See references/migration-engine-reference.md for the full output contract. Set MIGRATED_FOLDER = <SITE_FOLDER>V5.

Output: MIGRATED_FOLDER produced with rewritten files, swapped CSS, logs.txt, and diffs.

Phase 5: Review the Change Report

Goal: Turn logs.txt into a structured, grouped summary that surfaces the manual work.

Actions:

1. Read <MIGRATED_FOLDER>/logs.txt and categorize per the format documented in the engine reference. The report opens with three file lists — no change, auto-applied (Replacement/Addition/Deletion), and hierarchy changes (logged only) — followed by a per-file detail block (Total Number of Changes:<n> + change lines). Use Grep to count and locate the work:

   • Grep for Need hierarchy change → the manual hierarchy items (often zero).
   • The most reliable residual signal is the V5 output itself: Grep the migrated *.html for surviving Bootstrap-3 markers (page-header, glyphicon, label-(info|danger|primary), panel-(primary|success|info|warning|danger), btn-block, navbar-header). Whatever the engine left behind is exactly the Phase 6 work.

2. Present a summary:

   • Counts per category.
   • The list of files with hierarchy changes and CSS-dependent contextual classes (e.g. panel-primary) — these are the Phase 6 work items.

Output: Grouped change summary; explicit list of residual manual items.