Migration documentation

Create a page in the documentation for each and add it as a feature to features.yml and link to the docs. Keep it simple and base it off external guides.

• SVN
  • Docs https://docs.gitlab.com/ee/user/project/import/svn.html
• ClearCase
  • Docs https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13569
• Perforce
  • Docs https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13890
• CVS
  • Docs https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13928
• TFS
  • Docs https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13934

adding @JobV, @stanhu and @eliran.mesika to this issue.

For some reason can not add Kristen Lawrence to the issue.

Agree we should have a migration path, both documentation, technology and service to help with this. Kristen can help scope out the service piece of this. @eliran.mesika was in discussions with subgit.com as a technology to help mirror repos in svn to git.

I believe we're not doing subgit @ChadMalchow.

Moving from other systems is definitely something we can do a lot of engineering magic for. I'm less enthused to do this for legacy VCS, as this is very tricky and labor intensive. However, importing from competitors in the Git space and issue trackers we're very happy to do.

It would be great if TFS migration is also supported. It would be nice if this functionality was also supported in CE (in that case companies can try to migrate to GitLab without any risks).

we are currently running into issues at a couple of accounts (holding up the opportunities) in migrating from svn.

This customer has inquired about migration from SVN to GitLab. https://na34.salesforce.com/0036100000PTNrW

This prospect is interested in migration from SVN to GitLab. https://na34.salesforce.com/001610000120Exq

@Haydn can you add your customers asking for this too from you and your team?

Here is one I have looking to move from SVN to GitLab as well: https://na34.salesforce.com/00161000011zuBe

the need to help companies migrate from legacy vcs is an opportunity for us. There is a very large market of legacy vcs and they are moving to git. The solution which helps them migrate code and projects from these vcs will have an advantage. IMHO this is a perfect candidate for EEP or even better EEU.

Here is a report, https://na34.salesforce.com/00O61000003h3Jw, of at least 146 companies we have identified that have SVN. Here is a report of 85 companies that use clearcase, https://na34.salesforce.com/00O61000003h3Kz.

Concur to @ChadMalchow comment ... many enterprise company's are using legacy tools and have a dire need to move to Git. What's better, they aren't moving teams, they are moving groups, divisions, and even the entire organization.

If all you care about is your version history; Migrating from SVN to Git is a well worn path and a large number of tools exist to facilitate this, as well as a ginormous number of consultants with this expertise.

Moving from Naked Git to GitLab is trivial.

So I am not sure what a SVN-GitLab converter would buy you.

I suspect that the prospects are asking a BIGGER question - as just moving version data is only like 5% of what someone does in a migration to GitLab. Most likely the question is to migrate their existing systems off of an SVN based workflow to a GitLab based workflow, and that is much more complicated as they likely have a bazillion things that all expect to talk to a Subversion Depot, and that type of question is best addressed through a consulting engagement.

GitLab partners Intenso in the EU, and ReleaseTeam in the US, have extensive experience in this type of Migration. I would like to hear what @rkosiec and @hmorgan have to say.

Hi Team. This is where ReleaseTEAM can help. ReleaseTEAM has the expertise in all of these legacy tools and can help move opportunities forward by wrapping migration services with the software purchase. We have expertise in SVN, ClearCase, Perforce, Atlassian and Git. We can work with the customers on best practices and other pieces of the tool stack if needed. Migrations are more than 50% of ReleaseTEAM's current work. Due to the complexity under the legacy system, a converter would only be able to do so much. In an engagement, we are able to figure out what the goals of the organization are, interview the key players that work with the legacy tools and will work with the new tool, and see how the current environment works. This allows us to set up the migration in alignment with their goals, making the client successful and happy.

@hmorgan i agree they can help. but one issue is customers won't pay for migration in a trial. we usually get around that, but there are cases where they want to migrate for the trial.

@mrogge When you say trial are you talking about a pilot? Maybe there is a way we can work together to come up with a way we can package something together for these customers without a huge investment.

@hmorgan correct i use the term trial/pilot/poc interchangeably. but most are unpaid, so that's the issue. the ones that are paid i know we can work something out.

I agree with https://gitlab.com/gitlab-org/gitlab-ee/issues/2326#note_28713439 and https://gitlab.com/gitlab-org/gitlab-ee/issues/2326#note_28751931 It's one thing to migrate from a Git tool to GitLab but migrating from legacy VCS's is a different story, Subversion being the exception. There's loads of SVN->Git documentation (including our own) and some well used tools on the web (like https://git-scm.com/docs/git-svn ). So that leaves Clearcase, CVS and TFS as the main legacy VCS's. I think if we spent time putting together some docs on migrating from these three (like this Clearcase one ) it would certainly help but if the customer wants support or assistance with their migration, then they need a consulting engagement.

Hi, I'm Maciej Pleśnar from InTENSO. We got a rich history of such migration services with different tools (we are most experiences in Atlassian). Each migration case is a custom project for us. We usually perform a complex migrations, not only repos, but issues, wiki pages etc. We are capable of writing custom scripts to perform such complex migrations and support our customers on site. We would be happy to to help you in such cases. I agree that a dedicated GitLab migration documentation would be helpful, especially for other assets, not only GIT repo data.

Thank you Maciej for contributing. @malessio is our partners lead. Perhaps you and he can connect. Looks like you cover Europe, correct?