from h1 to h2 (#6743)

rules/do-you-create-a-migration-plan/rule.md

@@ -20,7 +20,7 @@ Migrating from .NET Framework (4.x) to the latest .NET (5+) brings huge advantag
 
 <!--endintro-->
 
-# Preparation
+## Preparation
 The migration to a newer version of .NET is the perfect opportunity for you to take stock of your current application architecture, and address any technical debt your app has accumulated. Trying to migrate an application that's poorly architected or carrying a lot of tech debt will make your migration **exponentially harder**. Therefore, now is the time to perform a full audit of your app and ensure you have PBIs to rectify these problems before you consider it "migration-ready".
 
 ### Dependency analysis
@@ -31,7 +31,7 @@ If your app has 3rd party dependencies (e.g. with a financial system, reporting
 ### Infrastructure
 If you host your app on premise, it's also worth checking your infrastructure to ensure it has the necessary runtimes.
 
-# Breaking changes
+## Breaking changes
 Once you've addressed any technical debt or architectural concerns, you can start gauging the amount of work involved in the migration itself.
 
 ::: greybox
@@ -63,7 +63,6 @@ try-convert --keep-current-tfms
 ```
 :::
 
-
 ### Change all your projects to be able to target multiple Target Framework Monikers (TFM)
 Now you have shiny new SDK-style `csproj` files, it's time to see what breaks!
 
@@ -118,7 +117,7 @@ By the end of this process, you'll have a much clearer view (and backlog!) of yo
 * PBIs for architectural concerns
 * PBIs for breaking changes
 
-# What's next?
+## What's next?
 While this guide aims to give you a high-level view of migrating your app, there are other some special considerations when dealing with complex applications and web apps. Check out these other rules:
 
 - [Migrating web apps to .NET Core](https://www.ssw.com.au/rules/migrating-web-apps-to-dotnet-core)