Can one change a group to a subgroup in GitLab?

For more current information, this feature has now been added to gitlab and you can transfer an existing group to become a subgroup of a different existing group.

The linked issue in @Zeta 's answer was closed and this issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/31885) became the primary issue on this topic.

At the time of writing this, the method to change a group to a subgroup is as follows:

1. go to the group you want to turn into a subgroup.
2. Go to the general settings of that group.
3. Expand "Path, transfer, remove".
4. Under this is a "Transfer group" box where you select your desired parent group that you manage.
5. After specifying the desired parent group, hit transfer group and it should be moved to the appropriate path.

Gitlab Notes (taken from gitlab web interface):

• Be careful. Changing a group's parent can have unintended side effects.
• You can only transfer the group to a group you manage.
• You will still need to update all local repositories.
• If the parent group's visibility is lower than the group current visibility, visibility levels for subgroups and projects will be changed to match the new parent group's visibility.

As of 2017-04-29, no. According to the subgroups issue on GitLab the transfer of subgroups is a feature that may come at some point in the future. The feature proposal itself ("Support the transfer of groups") got bumped lately (early June) and is planned to be ready in 2-3 months.

As a workaround you can:

1. Create your desired subgroup (e.g. FOO/BAR).
2. On the admin panel, open the group you originally wanted to move (e.g. FOO-BAR).
3. Open all group projects in new tabs.
4. The projects are now shown in admin view, so the namespace transfer does not need a name-confirmation. Also, since the desired group was created last, it should be the top one in the list. Transfer all projects to the namespace.
5. Head over to the member settings of both groups and make sure that FOO-BAR members have the same (or higher) rights in FOO/BAR.
6. The member settings on your projects should be intact.
7. Get ready to get yelled at because everyone needs to use git remote set-url.

I recommend to do those steps outside of regular business hours, since it will generate a bunch of emails ("project was moved", "access was granted"), and you probably want to write an email yourself to your members to explain what they have to do ("take the git remote set-url origin git@ and paste it into your shell on the right project").