GitHub Copilot on Azure Readiness starts here...

How I used GitHub Copilot to migrate my Hugo website to GitHub Pages

Sat, 13 Jun 2026 00:00:00 +0000

If you’ve followed this blog for a while, you know it runs on Hugo, a fantastic static site generator that turns a folder of Markdown files into a fast, fully static website. For the past couple of years that site has been hosted on Azure Static Web Apps, with an Azure DevOps pipeline doing the heavy lifting of compiling Hugo and publishing the output.

That setup served me well. After migration my old site templates and structure to a new one last February (see:https://www.pdtit.be/post/how-i-used-github-copilot-to-modernize-my-8-year-old-hugo-website/), I now wanted to consolidate everything into a single ecosystem and move the site to GitHub Pages, built and deployed by GitHub Actions. And because I wanted to see how far the tooling has come, I did the entire migration side-by-side with GitHub Copilot in agent mode inside VS Code.

Apart from moving the site, I also made the decision to decommission the 007FFFLearning.com brand, and go back to the “good-old” pdtit.be" one I had since the early days of the internet in 1996 already.

This post walks through why I made the move, what my old setup looked like, the plan I followed, and how the migration actually went, including the DNS part that always makes people nervous. I’m deliberately keeping it conceptual rather than copy-paste exact, so you can map it to your own site.

Here’s the prompt I used:

1
2
3


/plan a migration from this repo from azure static webapps with Hugo to a GitHub Pages environment. The goal is to migrate away from Azure hosting, Azure DevOps pipeline for the blog post updates and run everything in GitHub. The new domain name should be www.pdtit.be instead of www.007FFFLearning.com, as a redirection from pdtit.github.io default Pages name. Prepare a migration plan, identify the successes, potential risks and evaluation criteria to move the site.

If a migration is technically possible without losing functionality, highlight the actual steps to migrate, knowing we want a smooth migration with minimal downtime

// change draft: true to false

1. Why GitHub Pages for a static site?

A Hugo blog is, by definition, just a pile of static HTML, CSS, JavaScript and images once it’s built. You don’t need servers, containers, or databases to host it, you only need somewhere that can serve files over HTTPS. That’s exactly what GitHub Pages does, for free, directly from a repository.

A few reasons it’s a great fit:

One place for everything. Your content, your build pipeline, and your hosting all live in the same GitHub repo. No jumping between portals.
Build on push. With GitHub Actions, every push to your main branch rebuilds the site and publishes it automatically. Write a post, commit, done.
Free TLS and custom domains. GitHub Pages provisions a certificate for your own domain at no cost and can enforce HTTPS.
No build output in source control. The generated site is produced fresh in CI on every push, so you never have to commit the compiled HTML again.

For a personal blog, this removes a surprising amount of moving parts.

2. Where I was coming from (the old setup)

Before the migration, the moving pieces looked like this:

Hugo as the site generator, with content written in Markdown.
Azure Static Web Apps as the host, serving the compiled site and handling TLS for my custom domain.
An Azure DevOps pipeline that triggered on every commit, installed the right Hugo version, built the site, ran a couple of validation checks (more on that later), and deployed it.
The compiled output and even a copy of the Hugo binary were committed into the repository, a habit from earlier days that I wanted to leave behind.

Nothing here was broken. But it meant my publishing flow spanned two platforms (Azure DevOps for builds, Azure for hosting), and the repo carried a lot of generated weight it didn’t need.

3. The migration plan

Rather than diving straight into edits, I asked Copilot Plan mode to help me draft a phased plan first. Having a clear plan up front is what keeps a migration like this calm instead of chaotic. At a high level it broke down into:

Phase 1 - Prepare the repository. Stop committing build output. Add a .gitignore for the generated site, the Hugo cache, and any local binaries. Pin the exact Hugo version so local builds and CI builds always match.

Phase 2 - Recreate the build in GitHub Actions. Replace the Azure DevOps pipeline with a GitHub Actions workflow that installs Hugo, builds the site, and deploys it to Pages. Importantly, I carried over the validation checks my old pipeline did, things like confirming the search index was generated and that newly added posts actually appear in the output, so I didn’t lose that safety net.

Phase 3 - Publish to GitHub. Create the GitHub repository, point the local repo at it, rename the default branch to main, and push. Then flip the repo’s Pages setting to build from GitHub Actions.

Phase 4 - Custom domain. Tell GitHub which domain to serve, update the site’s base URL, configure DNS, and enforce HTTPS once the certificate is issued.

Phase 5 - Redirect the old domain. Keep the previous domain alive for a while and forward it to the new one so existing links and search engine results don’t break.

Phase 6 - Decommission the old platform. Once the new site is confirmed healthy, retire the Azure DevOps pipeline and the Azure Static Web App.

Writing the plan down also surfaced the risks early, the trickiest being deep links from the old domain and making sure the search feature kept working. Knowing those in advance meant I could check for them deliberately instead of discovering them after go-live.

4. How the migration actually went

With the plan agreed, the execution was honestly the easy part, this is where working alongside Copilot in agent mode really paid off. Instead of me hand-editing dozens of files, I described the outcome I wanted and reviewed the changes it proposed.

A few highlights of the actual approach:

Cleaning up the repo. The first win was getting the compiled site and the committed Hugo binaries out of version control. Going forward, the build output is regenerated by CI on every push, so the repository only contains what it should: content and configuration.

A single build-and-deploy workflow. The GitHub Actions workflow became the new “engine” of the site, the direct replacement for the old pipeline. On every push to main it installs the pinned Hugo version, builds the site, runs the validation checks, and deploys the result to Pages. The very first run going green was the moment I knew the new platform was viable.

Check out the actual GitHub Actions YAML if you want:

https://github.com/pdtit/pdtit.github.io/actions/runs/27473418917/workflow

Fixing up internal links. Because the domain was changing, I had Copilot sweep the content for hard-coded absolute links pointing at the old address and make them relative instead. Relative links survive a domain change without any further edits, which is exactly what you want.

Validating before trusting. Before pushing anything live, I rebuilt the site locally from a clean slate and verified the important things: the homepage and posts pointed at the new address, the client-side search index was present and valid, and no stale references lingered in the output. Only then did I publish.

The DNS part (kept high-level on purpose). This is the step people worry about most, but the pattern is well-trodden:

The www subdomain gets a CNAME pointing at the GitHub Pages host.
The root (apex) domain gets a set of A records (and IPv6 AAAA records) pointing at GitHub’s Pages addresses. GitHub publishes the exact values, you just enter them at your registrar.
GitHub then automatically redirects the apex to your www canonical address.

One gotcha worth calling out: if your registrar had any leftover parking or forwarding records on the apex, remove them, otherwise the certificate can struggle to provision. Once DNS resolved cleanly, GitHub issued the TLS certificate within minutes, and I switched on Enforce HTTPS.

Don’t strand the old domain. Finally, the previous domain stays alive and forwards to the new one. The key detail is to use a path-preserving redirect, so an old deep link to a specific article lands on that same article on the new domain, not just the homepage. That protects your existing readers and your search rankings while everything propagates.

Wrapping up

The migration itself, prepare, rebuild in Actions, publish, wire up the domain, redirect the old one, was conceptually simple, but having GitHub Copilot do the repetitive editing, validation, and verification turned what could have been a tense weekend into a calm afternoon. The site you’re reading this on right now is the result: a Hugo blog, built by GitHub Actions, served from GitHub Pages, on my own domain.

If you’re sitting on a static site hosted somewhere heavier than it needs to be, this is a very approachable move, and a great little project to try out agent-mode tooling on a real, low-risk task.

// should always be the last section of the blog

Cheers!!

/Peter

How I used GitHub Copilot to modernize my 8 year old Hugo website

Sat, 28 Feb 2026 00:00:00 +0000

I recently decided to give my 8 year old Hugo website a serious refresh. The trigger was simple: I still used the first Hugo theme I picked up 8 years ago, some content menu options didn’t actually do anything or were no longer relevant. Then I also had screenshots and other image files all over the place (5 different folder locations, duplicate image file names and alike).

Instead of doing this modernization and cleanup manually over a few weekends, I used GitHub Copilot as an active engineering partner to accelerate the full modernization journey.

Where it started: search was broken in production

The first issue looked small, but it exposed deeper reliability problems:

The search JSON endpoint existed
The /search/ page in production was effectively empty
The pipeline still reported success

So this wasnâ€™t a single typo. It was a classic â€œgreen pipeline, broken runtime behaviorâ€ scenario.

With Copilot, I moved from guessing to structured troubleshooting:

Validate generated Hugo output
Compare source routing/content metadata with deployed artifacts
Harden the pipeline to fail fast when critical pages are missing

That immediately changed the workflow from reactive debugging to proactive validation.

Copilot helped me modernize beyond just the bug

Once search was fixed, I used the same momentum to clean up years of accumulated content and asset drift.

1) Build and deployment reliability

I updated the Azure Static Web Apps pipeline to be more explicit and defensive:

Build validation checks for critical output files
Safer prebuilt artifact deployment behavior
Better guardrails so partial site generation doesnâ€™t silently pass

Result: deployment confidence went up significantly.

1) Build and deployment reliability

I updated the Azure Static Web Apps pipeline to be more explicit and defensive:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57


trigger:
 - main

pool:
 vmImage: 'ubuntu-latest'

steps:
 - task: UseHugoExtended@1
 inputs:
 version: 'latest'
 
 - script: hugo --minify
 displayName: 'Build Hugo site'
 
 # ðŸ›¡ï¸ GUARDRAIL: Validate critical output files exist
 - script: |
 if [ ! -f "public/search/index.json" ]; then
 echo "ERROR: Search JSON endpoint missing!"
 exit 1
 fi
 if [ ! -f "public/index.html" ]; then
 echo "ERROR: Homepage not generated!"
 exit 1
 fi
 displayName: 'Validate critical pages exist'
 
 # ðŸ›¡ï¸ GUARDRAIL: Check for empty or malformed search index
 - script: |
 SIZE=$(wc -c < public/search/index.json)
 if [ $SIZE -lt 100 ]; then
 echo "ERROR: Search index is suspiciously small ($SIZE bytes)!"
 exit 1
 fi
 displayName: 'Validate search index integrity'
 
 # ðŸ›¡ï¸ GUARDRAIL: Verify content pages were generated
 - script: |
 COUNT=$(find public -name "index.html" -type f | wc -l)
 if [ $COUNT -lt 10 ]; then
 echo "WARNING: Only $COUNT pages generated (expected more)"
 exit 1
 fi
 displayName: 'Verify minimum content threshold'
 
 - task: PublishBuildArtifacts@1
 inputs:
 pathToPublish: 'public'
 artifactName: 'hugo-site'
 displayName: 'Publish build artifacts'
 
 - task: AzureStaticWebApp@0
 inputs:
 azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_TOKEN)
 repo_token: $(GITHUB_TOKEN)
 action: 'upload'
 app_location: 'public'
 displayName: 'Deploy to Azure Static Web Apps'

Key safety improvements:

âœ… Explicit validation that search index exists and has realistic content
âœ… Minimum page count check to catch silent generation failures
âœ… Pipeline fails fast instead of deploying broken output
âœ… Clear error messages for debugging

Result: deployment confidence went up significantly.

2) Content architecture cleanup

Over time, I had duplicate and legacy routes (especially around books and videos). Copilot helped audit what was truly used versus what was just historical baggage.

I then:

Redesigned the Books page into a cleaner 2-column layout (cover + title/description)
Removed duplicate publications pages where canonical pages already existed
Reviewed and cleaned aliases to keep routing intentional

Result: fewer moving parts and clearer content ownership.

3) Image and asset governance

This was the biggest hidden technical debt.

I had images spread across multiple legacy folders with overlapping filenames. That made reference checks noisy and risky. Copilot helped me run source-scoped audits, identify true usage, and avoid false positives from generated output.

I used that to:

Move post-related images into content/post/images
Rewrite Markdown links in affected posts
Handle filename collisions safely
Remove unused files/folders only after reference validation

Result: cleaner repository, fewer dead assets, and lower risk of accidental content breakage.

What I liked most about using Copilot on an older codebase

The biggest value wasnâ€™t â€œAI wrote code for me.â€ It was this:

Faster root-cause analysis
Safer bulk refactoring with validation checkpoints
Less context switching for repetitive search/update tasks
Better confidence to remove legacy clutter without fear

For old websites, this matters a lot. Most of the work is not feature development â€” itâ€™s careful archaeology.

Practical lessons if you want to modernize your own Hugo site

If your site is aging and you donâ€™t know where to start, this sequence worked very well for me:

Fix one visible production issue first (high leverage)
Add pipeline checks for critical pages/artifacts
Identify canonical routes and remove duplicates
Consolidate assets by usage domain (e.g., post images)
Delete only after source-level reference validation

Small, verified steps beat one giant risky migration every time.

Final thoughts

This modernization started as a broken search page after switching to a new Hugo theme and ended as a full site health upgrade and removal of technical debt.

GitHub Copilot didnâ€™t replace engineering judgment â€” it amplified it. For me, that was the real win: I could move faster and be more careful at the same time.

If you have an older Hugo site (or any long-running static site), this is absolutely worth doing.

By the way, this whole process took less than 2 hours, and about 20 prompts in a continuous conversational approach. Are you a fan of GitHub Copilot? Let me know what your coolest use case has been so far!

Cheers!!

/Peter

Keeping MCP Server config in sync between VS Code and GitHub Copilot CLI

Thu, 26 Feb 2026 00:00:00 +0000

Syncing MCP config from VS Code to Copilot CLI in a few simple steps.

Hey awesome people,

Over the last weeks, Iâ€™ve been jumping between VS Code and Copilot CLI a lot more than usual. One thing kept annoying me: my MCP setup was perfect in VS Code, but I had to keep tweaking pieces again in CLI.

If that sounds familiar, good news: if you already have MCP servers working in VS Code, you can reuse most of that setup in GitHub Copilot CLI.

In this post, Iâ€™ll show you the fastest way to ‘keep both in sync’ from VS Code mcp.json to Copilot CLI mcp-config.json, with the necessary commands for both PowerShell and Bash.

Why this matters

When you move between VS Code and terminal workflows, you really donâ€™t want to rebuild MCP config from scratch every time.

I made that mistake once (probably multiple times, but didn’t want to exagerate too much…), and it was exactly as fun as it sounds: tiny syntax differences, one invalid server name, one missing env var, and suddenly youâ€™re troubleshooting config instead of actually building. (Although I can tell you that this would be a perfect use case for GenAI GitHub Copilot, lol)

This guide helps you:

keep one consistent MCP setup style (VSCode MCP Config as the ‘main’ source)
avoid common config parsing errors in Copilot CLI
‘keep-in-sync’ in a few minutes, even if youâ€™re new to MCP

MCP in plain English

MCP (Model Context Protocol) lets AI tools connect to external capabilities.

Think of MCP servers as â€œskill pluginsâ€ for your assistant, like:

documentation search
GitHub actions (issues, PRs, code search)
browser automation
Azure DevOps operations

File locations you should know

VS Code MCP config is typically found at:

Workspace: ./mcp.json or ./.vscode/mcp.json
User-level:
- Windows: %APPDATA%\\Code\\User\\mcp.json
- macOS: ~/Library/Application Support/Code/User/mcp.json
- Linux: ~/.config/Code/User/mcp.json

Copilot CLI MCP config lives here on all platforms:

~/.copilot/mcp-config.json

VS Code vs Copilot CLI: the important differences

The two formats are very close, but not identical:

Top-level key
- VS Code: servers
- Copilot CLI: mcpServers
Server ID naming rules in Copilot CLI
- allowed: letters, numbers, _, -
- server keys with / must be renamed
VS Code inputs
- supported in VS Code flow
- not used in Copilot CLI config
Placeholder syntax
- VS Code often uses ${env:VAR} and ${input:name}
- Copilot CLI expects $VAR and supports explicit env mappings

None of this is hard, but itâ€™s just different enough to break things when done manually in a hurry.

Fast path (recommended): automate conversion

You can grab both scripts directly from my GitHub repo:

https://github.com/petender/MCP-Clone_VSCode2CLI

Quick clone commands (PowerShell, bash, zsh):

1
2


git clone https://github.com/petender/MCP-Clone_VSCode2CLI.git
cd MCP-Clone_VSCode2CLI

Use one of these scripts:

convert-mcp-config.ps1 (Windows/macOS/Linux with pwsh)
convert-mcp-config.sh (macOS/Linux with bash + python3)

I personally use the PowerShell version most of the time, no surprise I’m primarily a Windows-guy, but didn’t want to assume everyone is using PowerShell nowadays. (You should though ;)

What the script converts automatically

servers -> mcpServers
removes VS Code-only inputs
converts ${input:name} -> $NAME
converts ${env:VAR} -> $VAR
adds/merges env mappings like "VAR": "$VAR"
renames invalid server IDs (for example containing /)

This is exactly the part that saves the most time (and avoids the most headaches).

PowerShell usage (`convert-mcp-config.ps1`)

The script supports cross-platform defaults using your home path.

Easiest mode

1

pwsh -ExecutionPolicy Bypass -File ./convert-mcp-config.ps1

This auto-discovers common input locations and writes to ~/.copilot/mcp-config.json.

Explicit input, default output

1
2


pwsh -ExecutionPolicy Bypass -File ./convert-mcp-config.ps1 \
 -InputPath ./mcp.json

Explicit input and output

1
2
3


pwsh -ExecutionPolicy Bypass -File ./convert-mcp-config.ps1 \
 -InputPath ./mcp.json \
 -OutputPath ~/.copilot/mcp-config.json

Custom home path

1
2
3


pwsh -ExecutionPolicy Bypass -File ./convert-mcp-config.ps1 \
 -InputPath ./mcp.json \
 -UserHome /home/<user>

Bash usage (`convert-mcp-config.sh`)

First run:

1

chmod +x ./convert-mcp-config.sh

Easiest mode

1

./convert-mcp-config.sh

Explicit input, default output

1

./convert-mcp-config.sh --input ./mcp.json

Explicit input and output

1

./convert-mcp-config.sh --input ./mcp.json --output ~/.copilot/mcp-config.json

Custom home path

1

./convert-mcp-config.sh --input ./mcp.json --user-home /home/<user>

Bash prerequisites

bash
python3

Verify in Copilot CLI

After conversion, open Copilot CLI and run:

/mcp reload
/mcp show

If your config is valid, your servers should load without parsing errors.

If they donâ€™t show up right away, donâ€™t panic. In most cases itâ€™s either naming rules or env vars (both covered below).

Required environment variables (for the sample config)

Set these before launching Copilot CLI:

GITHUB_PERSONAL_ACCESS_TOKEN
ADO_ORG
ADO_DOMAIN

PowerShell session example:

1
2
3


$env:GITHUB_PERSONAL_ACCESS_TOKEN = "<your_token>"
$env:ADO_ORG = "<your_ado_org>"
$env:ADO_DOMAIN = "core"

bash/zsh example:

1
2
3


export GITHUB_PERSONAL_ACCESS_TOKEN="<your_token>"
export ADO_ORG="<your_ado_org>"
export ADO_DOMAIN="core"

Manual conversion checklist

If you want to edit by hand, follow this sequence:

rename servers to mcpServers
remove inputs
replace ${input:name} with $NAME
replace ${env:VAR} with $VAR and add/update env
rename server IDs that contain unsupported characters
keep operational properties unchanged (type, command, args, url, version, gallery)

This checklist is also useful as a review checklist in PRs.

Common errors and quick fixes

`MCP server name must only contain alphanumeric characters, underscores, and hyphens`

Cause: a server key still contains / (or another invalid character).

Fix example:

microsoft/playwright-mcp -> microsoft_playwright_mcp

Server starts but fails with auth/runtime errors

Cause: missing or wrong environment variable values.

Fix:

validate variable names exactly
confirm values exist in the active shell session
run /mcp reload again

Also make sure you start Copilot CLI from the same shell/session where variables are set.

`command not found`

Cause: one of the required tools is missing.

Fix:

install dependencies used by your config (docker, npx, uvx, etc.)

Summary

Most VS Code MCP config can be reused in Copilot CLI. The key differences are server ID naming, top-level key name, and placeholder handling.

While one could assume that the MCP Configuration should be standardized across platforms, once I figured out the key syntax differences (GitHub Copilot for the win!), it ended up being much easier than I expected once I stopped doing it manually and automated the boring parts (GitHub Copilot for the win x2!).

If this helped you, feel free to share it with your team so everyone can standardize MCP config faster. And maybe give a little GitHub Star on the repo, so I know you like it ;).

Cheers!!

/Peter

Using GitHub Copilot Agent Mode to vibe code a Python shooting game

Fri, 28 Nov 2025 00:00:00 +0000

For about a year now, I’ve been teaching a lot on GitHub Copilot as part of my Microsoft role. Our program offers 2 different learning paths, one created by the Microsoft Content developers, AZ-2007, and the other one is managed by GitHub Content team, known as GH-300.

If you know my approach to teaching tech a bit, which a learner in my class lately called inspiring through technology, it means I’m trying to explain as much as possible through compelling, live demos. After walking learners through different GitHub Copilot features such as documenting/explaining code, generate application code (on different development frameworks), but also Azure CLI, CI/CD pipeline, Dockerfile, YAML, JSON and alike, I usually close with Agent Mode.

Having showed the first time in April when GitHub Copilot was still in preview, I usually show a demo where the Agent Mode builds me an ASP.NET webapp, modifies the Welcome home page, creates some sample employee data in a json-file, which then gets displayed in a table view in the webapp. If time allows, I also ask to then migrate everything into a SQLite setup, which brings in more complexity such as Entity Framework, SQL data migration steps and interaction with Azure KeyVault, since I specify I want to run this in Azure SQL, but not allowing connection strings in my appsettings.json.

(Now that I think about it, it might be another great blog post to write on in the near future…)

Earlier this week however, I came up with a new scenario, asking Agent Mode to develop a shooter game using Python code, bringing me back to my youth in the mid-80’s when I was playing such games on my first 486-PC.

Agent Mode Prompt

The prompt I used was this:

1
2
3
4
5
6
7
8
9


*"as a kid, I played arcade games a lot. I want to build a Python app, which tests me on my shooting reflexes. Help me developing a game which does the following:

1. aks for player name input
2. bottom middle of the game screen shows a shooter 
3. anywhere random on screen appears a target
4. player uses the space bar to simulate a shoot
5. calculate the time between the target appearing and player pressing the space bar to shoot
6. if that time is less than 0.3 sec, player wins, otherwise computer wins
7. show a "YOU WIN" or "YOU ARE TOO SLOW" dpeending on the outcome"

Agent Mode Processing

From here, the Agent started rolling…
Confirming with some sort of understanding what I asked for, followed by creating 3 todos:

Set Up Python Environment
Creating the Reflex Shooting Game
Testing the Game

This process took less than 1 minute, can you imagine? From there, it continued with providing detailed instructions on how to the game works.

Next, it also had a list of features included:

Time to start the game!!

Which allowed me to play exactly as I asked for. When I was too slow, it would tell me…

And several attempts later, I finally managed to win a game!!

Summary

I thought after using GitHub Copilot for training our customers and showing capabilities using live demos for about 5 hours per class, as well as using it for a lot of “coding” tasks as part of my role as trainer, mainly creating more demo scenarios (see Trainer-Demo-Deploy to get an idea what that means…), I thought I’d seen it all.

Yet, it keeps suprising me every single day when I try something new.

If I had access to this technology in the mid 80’s, I guess I would have spent more time learning about coding than playing games… although this game is actually pretty addicting already. Time to wrap up this post and go play a bit more! And feel 12 years old again.

If you want to see some similar version of this templategame in action, head over to my github repo.

Cheers!!

/Peter

Using GitHub Copilot Agent Mode to transform ARM templates to BICEP

Sat, 12 Jul 2025 00:00:00 +0000

Over the last few months, I’ve been working on an exciting project for our Microsoft Technical Trainer team, known as “Trainer-Demo-Deploy”, a catalog of Azure end-to-end demo scenarios, available as an Open-Source project.

While we managed to get about 50 templates live, there can never be enough scenarios to integrate into your Azure classes or POC activities if you ask me. One of the challenging tasks in the project is not only coming up with demo ideas, but also creating the actual artifacts, such as Azure templates with Bicep, sample apps and sample data.

I had an Azure Site Recovery Services scenario from a few years ago, written in modular ARM templates. With Bicep providing a great way to transform your ARM to Bicep, I could have gone through each template file and convert them. Have done several of those over the last few months.

But out of teaching AZ-2007 Accelerate app development by using GitHub Copilot, where I integrate a - what I think amazing demo on how to use Agent mode to deploy a sample web app - I started thinking about testing if Agent Mode could help me with this transformation project.

Fact I’m dedicating a blog post to it, is mainly to confirm it worked amazingly well, as well as sharing my excitement and some steps of what the process looked like. Hopefully this post inspires you to start embracing GitHub Copilot Agent Mode into your own tasks.

My starting templates

My original setup was pretty straightforward, having a folder “templates”, in which I have modular templates for each part of my Azure Site Recovery Vault deployment.

Each templates hold a snippet of ARM / JSON structured code to deploy one or more Azure Resources.

I opened up the folder structure in my Visual Studio Code, and opened GitHub Copilot, selecting Agent Mode. I clearly described in a prompt, what I wanted the Agent to perform as tasks. I didn’t provide much detail to be honest, as initially, I was merily experimenting to try and find out if Agent could actually help with this, or how far it would go in the process.

Agent Mode Prompt

The prompt I used was this: for each file in the templates folder, convert to azure bicep. create a new bicep file for each, keeping the same name as the original json file. the azuredeploy should be transformed to main.bicep. validate all pointers to all new bicep files to be correct"

From here, the Agent started rolling…
Informing me about the different steps it would take to handle this task, starting with exploring the templates folder to see all the files that need to be converted

Followed by going more in-depth into each and every template JSON file
Followed by starting the conversion process to Bicep files. Before doing that, it also highlighted it would check the Azure deployment best practices (although I didn’t explicitly asked to do that, nice one! )

It felt like it learned from the best practices, by starting with the azuredeploy.json conversion to main.bicep first. It could also be that it started with this, because I mentioned this in the prompt itself.

As the main.bicep conversion took a bit longer than normal - although it was only running over it for about a minute, it prompted, asking if it was ok to continue. Obviously, I confirmed to continue.

From here, it nicely continued looping through all smaller json-files, and transforming them into corresponding bicep-files. Since each file typically had only 1 or 2 resource references, the conversion went really smooth.

After a bit, it had finished the transformation of each ARM to Bicep, and started on updating the template links, as I asked for in my prompt, to also validate the references to all the deployment files.

With all references updated, it continued with its own error checking, and validating the different templates for any possible errors. Even more interesting, without me specifying, it detected an error in the azure.yaml, which I had in my project folder, from a baseline started AZD-template we use to create all our Trainer-Demo-Deploy scenarios.

Last, it also created a main.parameters.json, to capture any specific Parameters for the deployment.

From here, it went back to validating the Bicep templates again, where it detected a few different issues. (I didn’t check in detail what got identified as issue, as it didn’t prompt me to validate anything on my end…); based on the next informational message, it struggled with missing an output for myWorkspaceKey, in the deploy-infra.bicep file.

Chewing a bit on the myWorkspaceKey problem, it managed to find its own work-around to solve the problem. It even provided a clear explaining on why, identifying the dependency on the parent template.

Feeling we were close to the end of the process, it continued amazing me, as it now also created its own documentation in a BICEP_CONVERSION_SUMMARY.md Markdown file, in which it listed up what conversations it did.

With all that out of the way, it ran another final validation to conclude there were no more issues, closing the task with creating another README-BICEP.md file, describing how to run the actual deployment, using AZD.

Finally, the Agent provided a description within the Chat Agent window, clearly describing all the tasks accomplished with the necessary file references included:

As well as adding additional details on the task validation.

Finishing with describing different ways on how to run the actual deployment, using azd, Azure CLI and Azure PowerShell.

Last step was running the deployment, and this worked without any hiccups!

Summary

As mentioned earlier, I didn’t intend to go through this process as part of writing a blog post. Yet, the fact that the GitHub Copilot Agent Mode happily suprised me once more, I wanted to share my joy and excitement about this.

Starting from a somewhat complex JSON ARM template folder with about 10 modular arm-json files, it managed to nicely convert all of them into the new Bicep template language, with only a few minor issues throughout the process. Without asking assistance or halting the process, it ran its own troubleshooting and issue resolution, resulting in a 100% successful transformation.

Apart from the technical success of the task, what surprised me even more, is it only took the agent barely 5 minutes and only had to prompt me twice during the whole process!!

If you want to see this template in action, head over to my github repo and continue your Azure learning journey with more demo scenarios at Trainer-Demo-Deploy.

Cheers!!

/Peter

GitHub Copilot on Azure Readiness starts here...

How I used GitHub Copilot to migrate my Hugo website to GitHub Pages

1. Why GitHub Pages for a static site?

2. Where I was coming from (the old setup)

3. The migration plan

4. How the migration actually went

Wrapping up

How I used GitHub Copilot to modernize my 8 year old Hugo website

Where it started: search was broken in production

Copilot helped me modernize beyond just the bug

1) Build and deployment reliability

1) Build and deployment reliability

2) Content architecture cleanup

3) Image and asset governance

What I liked most about using Copilot on an older codebase

Practical lessons if you want to modernize your own Hugo site

Final thoughts

Keeping MCP Server config in sync between VS Code and GitHub Copilot CLI

Why this matters

MCP in plain English

File locations you should know

VS Code vs Copilot CLI: the important differences

Fast path (recommended): automate conversion

What the script converts automatically

PowerShell usage (convert-mcp-config.ps1)

Easiest mode

Explicit input, default output

Explicit input and output

Custom home path

Bash usage (convert-mcp-config.sh)

Easiest mode

Explicit input, default output

Explicit input and output

Custom home path

Bash prerequisites

Verify in Copilot CLI

Required environment variables (for the sample config)

Manual conversion checklist

Common errors and quick fixes

MCP server name must only contain alphanumeric characters, underscores, and hyphens

Server starts but fails with auth/runtime errors

command not found

Summary

Using GitHub Copilot Agent Mode to vibe code a Python shooting game

Agent Mode Prompt

Agent Mode Processing

Summary

Using GitHub Copilot Agent Mode to transform ARM templates to BICEP

My starting templates

Agent Mode Prompt

Summary

PowerShell usage (`convert-mcp-config.ps1`)

Bash usage (`convert-mcp-config.sh`)

`MCP server name must only contain alphanumeric characters, underscores, and hyphens`

`command not found`