diff --git a/docs/frontend-system/building-plugins/05-migrating.md b/docs/frontend-system/building-plugins/05-migrating.md
index 79b259a2e5..9d978869e5 100644
--- a/docs/frontend-system/building-plugins/05-migrating.md
+++ b/docs/frontend-system/building-plugins/05-migrating.md
@@ -8,7 +8,7 @@ description: How to migrate an existing frontend plugin to the new frontend syst
 
 This guide allows you to migrate a frontend plugin and its own components, routes, apis to the new frontend system.
 
-The main concept is that routes, components, apis are now extensions. You can use the appropriate extension creators to migrate all of them to extensions.
+The main concept is that routes, components, apis are now extensions. You can use the appropriate [extension blueprints](../architecture/23-extension-blueprints.md) to migrate all of them to extensions.
 
 ## Migrating the plugin
 
@@ -77,7 +77,7 @@ The code above binds all the extensions to the plugin. _Important_: Make sure to
 
 ## Migrating Pages
 
-Pages that were previously created using the `createRoutableExtension` extension function can be migrated to the new Frontend System using the `createPageExtension` extension creator, exported by `@backstage/frontend-plugin-api`.
+Pages that were previously created using the `createRoutableExtension` extension function can be migrated to the new Frontend System using the `PageBlueprint` [extension blueprint](../architecture/23-extension-blueprints.md), exported by `@backstage/frontend-plugin-api`.
 
 For example, given the following page:
 
@@ -94,28 +94,30 @@ export const FooPage = fooPlugin.provide(
 it can be migrated as the following:
 
 ```tsx
-import { createPageExtension } from '@backstage/frontend-plugin-api';
+import { PageBlueprint } from '@backstage/frontend-plugin-api';
 import {
   compatWrapper,
   convertLegacyRouteRef,
 } from '@backstage/core-compat-api';
 
-const fooPage = createPageExtension({
-  defaultPath: '/foo',
-  // you can reuse the existing routeRef
-  // by wrapping into the convertLegacyRouteRef.
-  routeRef: convertLegacyRouteRef(rootRouteRef),
-  // these inputs usually match the props required by the component.
-  loader: ({ inputs }) =>
-    import('./components/').then(m =>
-      // The compatWrapper utility allows you to use the existing
-      // legacy frontend utilities used internally by the components.
-      compatWrapper(<m.FooPage />),
-    ),
+const fooPage = PageBlueprint.make({
+  params: {
+    defaultPath: '/foo',
+    // you can reuse the existing routeRef
+    // by wrapping into the convertLegacyRouteRef.
+    routeRef: convertLegacyRouteRef(rootRouteRef),
+    // these inputs usually match the props required by the component.
+    loader: ({ inputs }) =>
+      import('./components/').then(m =>
+        // The compatWrapper utility allows you to use the existing
+        // legacy frontend utilities used internally by the components.
+        compatWrapper(<m.FooPage />),
+      ),
+  },
 });
 ```
 
-then add the `fooPage` extension to the plugin:
+Then add the `fooPage` extension to the plugin:
 
 ```ts title="my-plugin/src/alpha.ts"
   import { createFrontendPlugin } from '@backstage/frontend-plugin-api';
@@ -133,7 +135,7 @@ then add the `fooPage` extension to the plugin:
 
 ## Migrating Components
 
-The equivalent utility to replace components created with `createComponentExtension` is `createExtension` from `@backstage/frontend-plugin-api`. However, we recommend searching for a more appropriate extension creator first.
+The equivalent utility to replace components created with `createComponentExtension` depends on the context within which the component is used, typically indicated by the naming pattern of the export. Many of these can be migrated to one of the [existing blueprints](03-extension-blueprints.md), but in rare cases it may be necessary to use [`createExtension`](../architecture/20-extensions.md#creating-an-extension) directly.
 
 ## Migrating APIs
 
@@ -182,7 +184,7 @@ const exampleWorkApi = createApiFactory({
 The major changes we'll make are
 
 - Change the old `@backstage/core-plugin-api` imports to the new `@backstage/frontend-plugin-api` package as per the top section of this guide
-- Wrap the existing API factory in a `createApiExtension`
+- Wrap the existing API factory in a `ApiBlueprint`
 
 The end result, after simplifying imports and cleaning up a bit, might look like this:
 
@@ -190,17 +192,19 @@ The end result, after simplifying imports and cleaning up a bit, might look like
 import {
   storageApiRef,
   createApiFactory,
-  createApiExtension,
+  ApiBlueprint,
 } from '@backstage/frontend-plugin-api';
 import { workApiRef } from '@internal/plugin-example-react';
 import { WorkImpl } from './WorkImpl';
 
-const exampleWorkApi = createApiExtension({
-  factory: createApiFactory({
-    api: workApiRef,
-    deps: { storageApi: storageApiRef },
-    factory: ({ storageApi }) => new WorkImpl({ storageApi }),
-  }),
+const exampleWorkApi = ApiBlueprint.make({
+  params: {
+    factory: createApiFactory({
+      api: workApiRef,
+      deps: { storageApi: storageApiRef },
+      factory: ({ storageApi }) => new WorkImpl({ storageApi }),
+    }),
+  },
 });
 ```