diff --git a/menu/navigation.json b/menu/navigation.json
index 17a8d1cecf..af51c302d3 100644
--- a/menu/navigation.json
+++ b/menu/navigation.json
@@ -414,6 +414,10 @@
                     "label": "Permission sets",
                     "slug": "permission-sets"
                   },
+                  {
+                    "label": "IAM Guests to Members migration",
+                    "slug": "guests-to-members-migration"
+                  },
                   {
                     "label": "Reproducing roles and Project-scoped API keys with IAM",
                     "slug": "reproduce-roles-project-api-keys"
diff --git a/pages/iam/reference-content/guests-to-members-migration.mdx b/pages/iam/reference-content/guests-to-members-migration.mdx
new file mode 100644
index 0000000000..47b348645e
--- /dev/null
+++ b/pages/iam/reference-content/guests-to-members-migration.mdx
@@ -0,0 +1,86 @@
+---
+meta:
+  title: IAM Guests to Members migration
+  description: Learn how to migrate IAM Guests to Members, including roles and API keys, with Scaleway's IAM introduction
+content:
+  h1: IAM Guests to Members Migration
+  paragraph: This page guides you through the process of migrating IAM Guests to Members, covering key aspects such as roles and API keys, following the introduction of IAM on Scaleway
+tags: iam migration
+categories:
+  - iam
+  - console
+---
+
+This document explains how user management changes with the migration of IAM Guests to Members.
+
+## IAM Users
+
+A user (also known as an IAM user) is a human user in an Organization. Three types currently exist:
+
+- **Owner**: You are the Owner of the [Organization](#organization) that was created with your account.
+- **Guest**: You are a Guest when invited to another Organization of which you are not the Owner.
+- **Member**: You are a Member when you are added to an Organization by an Owner or user with IAM Manager permissions. Members exist only within the specific Organizations in which they are created.
+
+Whereas Owners have full rights and access to all resources and features in their Organization, Guests and Members have only the rights and permissions given to them via [policies](#policy).
+
+## IAM Guests become IAM Members
+
+From June 2025, IAM Guests will become IAM Members. The migration process will be carried out in two phases:
+
+    - **Phase 1** - Starting on the *18th of July 2025*, the [manual migration of Guests](#how-to-manually-migrate-a-user-from-guest-to-member) will be available in the Console to all Owners and users with [IAMManager permissions](/iam/reference-content/permission-sets).
+    - **Phase 2** - Starting in *July 2025*, Guests that have not yet become Members will be automatically migrated.
+
+Keep in mind that:
+
+- Members exist only within the Organizations in which they were created, and have a [dedicated login process](/iam/how-to/log-in-as-a-member).
+- Migrating a Guest to a Member does not mean that the Guest loses the Organization of which they are Owner. However, when creating Members in the future who do not already have Scaleway accounts, they will not be obliged to create their own Organization.
+- Organization admins manage Member accounts, including enforcing security requirements (MFA, password renewal).
+- Single Sign-On (SSO) remains available.
+- The management of API keys, IAM policies, and groups remains the same.
+
+### What remains the same?
+
+| Feature | for Members |
+|:--------:|----------|
+| Single Sign-On (SSO) | Available |
+| Credentials (Password, SSO, MFA) |   Members who previously existed as Guests maintain the same credentials configuration as before. |
+| Access control |   Like Guests, Members are granted permissions to the Organization by way of IAM policies.  |
+| API keys |  The processes for creating, viewing and deleting API keys remain the same.  |
+
+### What changes?
+
+The table below summarizes the key account and access management features that Scaleway offered prior to IAM, and if/how they change with the introduction of Members. For more information, see the relevant sections of this document below.
+
+| Feature | Guests | Members |
+|:--------:|:---------:|:---------:|
+| Login | Guests logged into their own accounts and could access all Organizations they were a part of via the console. | Currently, Members must log into each of their Organizations separately to access them. If they log into an Organization, then want to access a different one using the same email, they must log out of the former first. |
+| Enforcement of MFA | It was not possible to enforce MFA if a Guest in your Organization had not enabled MFA in their account. Organization admins could send reminder emails, but had to wait for the Guest to enable MFA, or remove them from the Organization to complete the enforce process. | When MFA is enforced in the Organization, Members have a [grace period](iam/concepts/#grace-period) to enable MFA in their accounts. This period is set by the Organization admins and starts as soon as a new Member is added. If they fail to enable MFA within this period, their accounts are locked. |
+| Password renewal | Guests were not required to renew their passwords to stay in an Organization. | As a security measure, Organization admins can require Members to renew their passwords within a grace period. If a password was attributed to Members upon their creation, they must renew this password after their first login. |
+| User management | Guest accounts and personal Organizations could not be managed by anyone other than them. Their permissions on Organizations they were invited to are the prerogative of Organization admins. | Member accounts are an 100% manageable resource - they can be created, updated, locked and deleted by Organization admins. |
+| Organizations | Guests were users who had their own personal Organizations and were invited into another. They had full management rights on their accounts and Organizations. If they were removed from an Organization, they would continue to have a Scaleway account. |   Members exist only within an Organization and can be present in solely said Organization. Members cannot own Organizations. They must [comply to the security requirements](/iam/how-to/comply-with-sec-requirements-member) set for the Organization to ensure their continuous access.  |
+
+## How to manually migrate a user from Guest to Member
+
+<Message type="important">
+  The migration does not have any impact on your production.
+</Message>
+
+<Macro id="requirements" />
+
+- A Scaleway account logged into the [console](https://console.scaleway.com)
+- [Owner](/iam/concepts/#owner) status or [IAMManager permissions](/iam/concepts/#permission)
+
+1. Click **IAM & API keys** on the top-right drop-down menu of the Scaleway console. The **Users** tab of the [Identity and Access Management dashboard](https://console.scaleway.com/iam/users) displays.
+2. Click **Switch to Members** in the *Switch to IAM Members* top banner. A pop-up appears providing information about Member features.
+3. Click **Next**. More information about the changes for your users displays.
+4. Click **Next** again.
+5. Type **MIGRATE**.
+    <Message type="important">
+      Make sure you are sure of migrating before continuing. Switching to Members is a one-time irreversible action.
+    </Message>
+6. Click **Migrate**.
+    <Message type="note">
+      The migration might take up to one minute.
+    </Message>
+
+You receive an email to confirm the migration. The former Guests, now Members, also receive an email with their credentials instructions on how to log in as a member for the first time.
\ No newline at end of file