address comments from Richard Murillo

Author: JoeStech

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/2-environment-setup.md

@@ -40,6 +40,8 @@ docker --version
 
 Expected output: `Arm` (kernel strings may still show architecture-specific values). Ensure the .NET SDK version is 9.0.x.
 
+If you are upgrading from an older .NET version before migrating to Cobalt, you can use [GitHub Copilot modernization for .NET](https://learn.microsoft.com/dotnet/core/porting/github-copilot-app-modernization/overview) to assess the project and guide the upgrade. In Visual Studio Code, open Copilot Chat and use `@modernize-dotnet`; in Visual Studio, use the Modernize action from Solution Explorer.
+
 ## PostgreSQL prerequisite for nopCommerce install
 
 nopCommerce defaults to SQL Server, but this learning path uses PostgreSQL for Arm validation. For PostgreSQL installs, `citext` is required before migration/installation. Without it, installer migrations fail with `type "citext" does not exist` (captured in local test artifacts).

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/5-containerization.md

@@ -35,10 +35,11 @@ dotnet publish src/Presentation/Nop.Web/Nop.Web.csproj \
 
 ### 3. .NET SDK multi-arch path
 
-Define multi-arch runtime identifiers in the project file, then publish once.
+Define runtime identifiers and multi-arch container runtime identifiers in the project file, then publish once.
 
 ```xml
 <PropertyGroup>
+  <RuntimeIdentifiers>linux-x64;linux-arm64</RuntimeIdentifiers>
   <ContainerRuntimeIdentifiers>linux-x64;linux-arm64</ContainerRuntimeIdentifiers>
 </PropertyGroup>
 ```
@@ -50,6 +51,16 @@ dotnet publish src/Presentation/Nop.Web/Nop.Web.csproj -c Release /t:PublishCont
 
 This is the scalable path for one image definition across both architectures.
 
+## SDK version guardrail
+
+Before choosing the SDK publish path for multi-architecture images, check the SDK version used by CI and by developer workstations:
+
+```bash
+dotnet --version
+```
+
+If you cannot use a .NET SDK version that supports multi-RID container publishing, or if SDK publish does not produce the multi-architecture image index you need, use the `docker buildx build --platform linux/amd64,linux/arm64` workflow instead. Multi-RID container publishing starts with .NET SDK versions 8.0.405, 9.0.102, and 9.0.2xx.
+
 ## Recommendation
 
 Use SDK publish as the default migration path. Use a Dockerfile workflow for advanced layer control or custom build logic.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/6-deploy-verify-cobalt.md

@@ -12,9 +12,10 @@ Treat tuning as an experiment pipeline, not a one-shot tweak. On Arm, apply chan
 
 ## Tuned run configuration
 
-Start with a conservative runtime profile that is commonly effective for server workloads.
+Start with a conservative runtime profile that is commonly effective for server workloads. Keep these settings outside the application code at first so you can switch profiles without rebuilding.
 
 ```bash
+export DOTNET_TieredCompilation=1
 export DOTNET_TieredPGO=1
 export DOTNET_ReadyToRun=1
 export DOTNET_gcServer=1
@@ -23,6 +24,26 @@ export DOTNET_EnableDiagnostics=0
 export DOTNET_ThreadPool_ForceMinWorkerThreads=2
 ```
 
+Increase `DOTNET_ThreadPool_ForceMinWorkerThreads` only when traces or load-test data show thread-pool starvation.
+
+### Optional spin-wait experiment for .NET 8, 9, and 10
+
+If the workload burns CPU while waiting for short-lived thread-pool work, test disabling the thread-pool unfair semaphore spin limit:
+
+```bash
+export DOTNET_ThreadPool_UnfairSemaphoreSpinLimit=0
+```
+
+Treat this as an experiment, not a default. Turning off spin waiting can reduce wasted CPU on small instances or oversubscribed containers, but it can also increase wake-up latency and reduce peak throughput. Validate it separately from the base tuned profile.
+
+### Tiered PGO and ReadyToRun optimize different phases
+
+`DOTNET_TieredPGO=1` and `DOTNET_ReadyToRun=1` are not the same optimization:
+
+- `ReadyToRun` favors startup and early request latency by using precompiled code when it is available.
+- `TieredPGO` favors steady-state throughput by letting the JIT recompile hot methods with runtime profile data.
+- Test them together and separately if startup latency and warmed throughput both matter.
+
 Run the same endpoint suite used in the baseline:
 
 ```bash
@@ -44,6 +65,10 @@ Use these rules before adopting a tuning profile:
 - Require improvement in both throughput and p95 latency, not just one.
 - Set a minimum practical threshold (for example, >=5% median gain) before rollout.
 
+## Instance-size tradeoffs
+
+Do not assume the same profile wins on every Azure Cobalt VM size. Smaller instances often benefit from lower CPU burn and predictable p95 latency. Larger instances often benefit from higher concurrency, but can expose GC, database, and shared-resource contention. Compare throughput, p95/p99 latency, CPU utilization, and error rate for each instance size before keeping a tuning profile.
+
 ## Interpretation
 
 - If only one metric improves while p95 or error rate regresses, do not treat the change as a win.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/7-arm-mcp-server.md

@@ -65,7 +65,7 @@ On this Ubuntu Neoverse (Azure Cobalt) instance:
 
 Typical optimization actions include:
 
-- Runtime settings (`DOTNET_TieredPGO`, `DOTNET_ReadyToRun`, thread pool tuning)
+- Runtime settings (`DOTNET_TieredPGO`, `DOTNET_ReadyToRun`, thread pool tuning, and spin-wait experiments)
 - Container/runtime configuration cleanup
 - Architecture-conditional deployment settings
 - Repeated measurement loops with fixed workload parameters and fixed endpoint order

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/_index.md

@@ -43,6 +43,10 @@ further_reading:
         title: .NET SDK container publish overview
         link: https://learn.microsoft.com/dotnet/core/containers/overview
         type: documentation
+    - resource:
+        title: GitHub Copilot modernization for .NET
+        link: https://learn.microsoft.com/dotnet/core/porting/github-copilot-app-modernization/overview
+        type: documentation
     - resource:
         title: .NET on Arm
         link: https://learn.microsoft.com/dotnet/core/install/linux-arm64
@@ -57,4 +61,4 @@ further_reading:
 weight: 1                       # _index.md always has weight of 1 to order correctly
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
----
+---