diff --git a/docs/getting_started.rst b/docs/getting_started.rst
index 2a3aab7..65324f8 100644
--- a/docs/getting_started.rst
+++ b/docs/getting_started.rst
@@ -16,8 +16,8 @@ workflow can be summarized in the following steps:
 1. Create an organization (the target organization).
 2. Configure RepoBee for the target organization.
 3. Verify settings.
-4. Migrate master repositories into the target organization.
-5. Create one copy of each master repo for each student.
+4. Setting up the master repos.
+5. Setting up the student repos.
 
 There is more to RepoBee, such as opening/closing issues, updating student
 repos and cloning repos in batches, but here we will just look at the bare
@@ -150,9 +150,9 @@ recommend having a separate, persistent organization so that you can work on
 repos across course rounds. If you already have a master organization with your
 master repos set up somewhere, and ``master_org_name`` is specified in the
 config, you're good to go. If you need to migrate repos into the target
-organization (i.e. you are not using a master organization), see the
-:ref:`migrate` section. For all commands but the ``migrate`` command, the way
-you set this up does not matter as RepoBee commands go.
+organization (e.g. if you keep master repos in the target organization), see
+the :ref:`migrate` section. For all commands but the ``migrate`` command, the
+way you set this up does not matter as far as RepoBee commands go.
 
 .. _setup:
 
diff --git a/docs/migrate.rst b/docs/migrate.rst
index cdc8863..09cb674 100644
--- a/docs/migrate.rst
+++ b/docs/migrate.rst
@@ -1,16 +1,18 @@
 .. _migrate:
 
-Migrate master repositories into the target (or master) organization (``migrate`` command)
-******************************************************************************************
-This step sounds complicated, but it's actually very easy, and can be performed
-with a single RepoBee command. There is however a pre-requisite that must
-be fulfilled. You must either
+Migrate repositories into the target (or master) organization (``migrate`` command)
+***********************************************************************************
+Migrating repositories from one organization to another can be useful in a few
+cases. You may have repos that should be accessible to students and need to be
+moved across course rounds, or you might be storing your master repos in the
+target organization and need to migrate them for each new course round. To
+migrate repos into the target organization, they need to be either:
 
-* Have local copies of your master repos.
+* Local in the current working directory, and specified by name.
 
 or
 
-* Have all master repos in the same GitHub instance as your target organization.
+* Somewhere in the target GitHub instance, and specified by URL.
 
 Assuming we have the repos ``master-repo-1`` and ``master-repo-2`` in the
 current working directory (i.e. local repos), all we have to do is this:
@@ -18,7 +20,6 @@ current working directory (i.e. local repos), all we have to do is this:
 .. code-block:: bash
 
     $ repobee migrate -mn master-repo-1 master-repo-2
-    [INFO] created team master_repos
     [INFO] cloning into file:///some/directory/path/master-repo-1
     [INFO] cloning into file:///some/directory/path/master-repo-2
     [INFO] created repobee-demo/master-repo-1
@@ -34,16 +35,15 @@ current working directory (i.e. local repos), all we have to do is this:
     you must specify it with the ``--org-name`` option here (instead of the
     ``--master-org-name``).
 
-There are a few things to note here. First of all, the team ``master_repos`` is
-created. This only happens the first time ``migrate`` is run on a new
-organization. As the name suggests, this team houses all of the master repos.
-Each master repo that is migrated with the ``migrate`` command is added to this
-team, so they can easily be found at a later time. It may also be confusing that
-the local repos are being cloned (into a temporary directory). This is simply
-an implementation detail that does not need much thinking about. Finally, the
-local repos are pushed to the ``master`` branch of the remote repo. This command
-is perfectly safe to run several times, in case you think you missed something.
-Running the same thing again yields the following output:
+What happens here is pretty straightforward, except for the local repos being
+cloned, which is an implementation detail that does not need to be thought
+further of. Note that only the defualt branch is actually migrated, and pushed
+to ``master`` in the new repo. local repos are pushed to the ``master`` branch
+of the remote repo. Migrating several branches is something that we've never
+had a need to do, but if you do, please open an issue on GitHub with a feature
+request. ``migrate`` is perfectly safe to run several times, in case you think
+you missed something, or need to update repos. Running the same thing again
+without changing the local repos yields the following output:
 
 .. code-block:: bash
 
@@ -59,8 +59,7 @@ Running the same thing again yields the following output:
 
 In fact, all RepoBee commands that deal with pushing to or cloning from
 repos in some way are safe to run over and over. This is mostly because of
-how git works, and has little to do with RepoBee itself. Now that
-our master repos are migrated, we can move on to setting up the student repos!
+how Git works, and has little to do with RepoBee itself.
 
 .. note::
 
diff --git a/repobee/cli.py b/repobee/cli.py
index 0c7cf53..5215ca3 100644
--- a/repobee/cli.py
+++ b/repobee/cli.py
@@ -621,11 +621,7 @@ def _add_subparsers(parser):
             "Migrate master repositories into the target organization. "
             "The repos must either be local on disk (and specified with "
             "`-mn`), or somewhere in the target GitHub instance (and "
-            "specified with `-mu`). Migrate repos are added to the `{}` "
-            "team. `migrate-repos` can also be used to update already "
-            "migrated repos, by simply running the command again.".format(
-                command.MASTER_TEAM
-            )
+            "specified with `-mu`)."
         ),
         parents=[base_parser, base_user_parser],
     )
diff --git a/repobee/command.py b/repobee/command.py
index 86887b6..1cd50c1 100644
--- a/repobee/command.py
+++ b/repobee/command.py
@@ -36,8 +36,6 @@ from repobee.git import Push
 
 LOGGER = daiquiri.getLogger(__file__)
 
-MASTER_TEAM = "master_repos"
-
 
 def setup_student_repos(
     master_repo_urls: Iterable[str],
@@ -393,8 +391,6 @@ def migrate_repos(master_repo_urls: Iterable[str], api: GitHubAPI) -> None:
         the username that is used in the push.
         api: A GitHubAPI instance used to interface with the GitHub instance.
     """
-    master_team, *_ = api.ensure_teams_and_members({MASTER_TEAM: []})
-
     master_names = [util.repo_name(url) for url in master_repo_urls]
 
     infos = [
@@ -402,7 +398,6 @@ def migrate_repos(master_repo_urls: Iterable[str], api: GitHubAPI) -> None:
             name=master_name,
             description="Master repository {}".format(master_name),
             private=True,
-            team_id=master_team.id,
         )
         for master_name in master_names
     ]

diff --git a/tests/test_command.py b/tests/test_command.py
index 9d09848..e423071 100644
--- a/tests/test_command.py
+++ b/tests/test_command.py
@@ -600,9 +600,9 @@ class TestMigrateRepo:
 
         git_clone_mock.assert_has_calls(expected_clone_calls)
         assert api_mock.create_repos.called
-        api_mock.ensure_teams_and_members.assert_called_once_with(
-            {command.MASTER_TEAM: []}
-        )
+        assert (
+            not api_mock.ensure_teams_and_members.called
+        ), "master repos should no longer be added to a team"
         git_push_mock.assert_called_once_with(expected_pts)
 
 

Don't add migrated repos to `master_repos` team
`migrate` is probably most useful for moving course content that students should actually be able to access, so adding it to the `master_repos` team is inconvenient. There's also the fact that since the `migrate` command was introduced, the recommended way of storing master repos has changed from keeping them in the target org, to keeping them in a separate master org. That, and the fact that it introduces a new namespace on GitLab, which complicates cloning master repos that are housed in the target organization.

This does not actually affect any functionality in RepoBee, as the `master_repos` team is not used anywhere, so it's safe to just remove.
tests/test_command.py::TestMigrateRepo::test_happy_path
tests/test_command.py::TestSetupStudentRepos::test_raises_on_clone_failure tests/test_command.py::TestSetupStudentRepos::test_raises_on_duplicate_master_urls tests/test_command.py::TestSetupStudentRepos::test_happy_path tests/test_command.py::TestUpdateStudentRepos::test_raises_on_duplicate_master_urls tests/test_command.py::TestUpdateStudentRepos::test_happy_path tests/test_command.py::TestUpdateStudentRepos::test_issues_on_exceptions[issue0] tests/test_command.py::TestUpdateStudentRepos::test_issues_on_exceptions[None] tests/test_command.py::TestUpdateStudentRepos::test_issues_arent_opened_on_exceptions_if_unspeficied tests/test_command.py::TestOpenIssue::test_happy_path tests/test_command.py::TestCloseIssue::test_happy_path tests/test_command.py::TestCloneRepos::test_happy_path tests/test_command.py::TestListIssues::test_happy_path[slarse-True--closed] tests/test_command.py::TestListIssues::test_happy_path[slarse-True-^.*$-closed] tests/test_command.py::TestListIssues::test_happy_path[slarse-False--closed] tests/test_command.py::TestListIssues::test_happy_path[slarse-False-^.*$-closed] tests/test_command.py::test_purge_review_teams tests/test_command.py::TestAssignPeerReviewers::test_too_few_students_raises[3-3] tests/test_command.py::TestAssignPeerReviewers::test_too_few_students_raises[3-4] tests/test_command.py::TestAssignPeerReviewers::test_zero_reviews_raises tests/test_command.py::TestAssignPeerReviewers::test_happy_path