Skip to content

Manage:Import - Vision & Roadmap for FY24

Vision Section

Vision & Direction:

  • What problem you are solving ( Skip talking about solution at this point)
  • Why does it matter to the user and why does it matter to GitLab
  • Elaborate the use-case (suggested: Jobs-to-be-done format )

Problem 1: Customers are not able to easily and reliably migrate their resources between and within GitLab instances. Migration is unreliable for large customers especially. There's no flexibility offered in regards to what can be migrated.

AIM: Customers of all sizes are able to easily and reliably migrate their resources between and within GitLab instances.

It matters to the users, because it will:

  • Support decisions on where to host projects and any further changes.
  • Facilitate company acquisitions and mergers.
  • Enable saving money, time and other resources.

It matters to GitLab, because it will:

  • Increase customer satisfaction which will positively impact revenue.
  • Bring more customers to SaaS, which supports GitLab hosted first objective.

Jobs To Be Done (with proposed solutions):

A. I want to easily migrate users between different GitLab instances while keeping their contributions

  • Automatic user migration
  • No preparation steps required to preserve user contributions
  • Contributions of users that are ex-employees get preserved

B. I want to import all group and project resources that are relevant to me.

  • Import additional project resources

C. I want to easily find info on how to move to GitLab.com.

  • Deprecating old solutions
  • Easy to find from search engines

D. I want to easily understand the docs, estimate the effort required and assess if my organization setup meets the requirements for using the tool.

  • Docs listing requirements (prerequisites, preparation steps, recommended versions)
  • Docs listing known problems
  • Automated checks against requirements
  • Dry run - feedback without actually importing (“you would be importing that many”, “there are problems with this and that”) (maybe)
  • Assessment of import duration

E. I want to minimize the impact of migration to my business.

  • Migration doesn't pose security risks for my business
  • Migration doesn’t overwhelm my system
  • Import is as fast as it can be

F. I want to perform groups and projects imports efficiently, with little friction.

  • Pre-migration validations allow to fail fast
  • I can easily select only what I need to import
  • UI supports fast selection
  • The process is as efficient as it can be
  • The process scales to any size of groups and projects

G. If I make a mistake or migration fails for any reason, I want to undo and redo things efficiently.

  • I can retry chosen parts of the import that failed (group/subgroup/relations)
  • I can cancel started migration
  • I can clean up

H. I want to know how the import is progressing and how long it’s going to take

  • Progression indication in UI, via API

I. Should an issue occur, I want to be able to self-help

  • The application gives users actionable feedback on what happened and how to solve it

J. I want to receive high quality support: fast and that solves my problems.

  • Good logs - clear log messages, easy to find logs for specific users, specific relations.

K. I want to understand the result of the import

  • What was imported
  • What was not imported
  • Why something was not imported (does it make sense to repeat, do I need to solve/fix something or contact customer service)

L. I want to easily and efficiently migrate resources from or between offline GitLab instances.

  • Extend migration by direct transfer to support offline environments

Problem 2: Customers cannot yet import all relevant GitHub concepts to GitLab.

AIM: Customers are able to easily and reliably import to GitLab all relevant GitHub concepts for projects of all sizes.

It matters to the users, because it will:

  • Support decisions on where to host projects.
  • Enable saving money, time and other resources.

It matters to GitLab, because it will:

  • Create a positive first impression when adopting GitLab.
  • Support GitLab’s expansion on the market.

Jobs To Be Done (with proposed solutions) - TBD

Overview of group's categories

List your categories and what purpose does each category serve

~"Category:Importers"

  • Import projects from external providers to GitLab.
  • Migrate resources between and within GitLan instances.

~"Category:Internationalization"

  • Translate GitLab application to many languages.
  • Localize GitLab for as many countries and regions as possible

Strategy section

Competitive Analysis

  • List of competitors you evaluated ( suggested list here )
  • What is their offering and their competitive advantage [ One format to use is list down jobs-to-be-done / user journey, map it to the tool competitor offers and put down the advantage for it ]
  • Compare the pricing, any stickiness you observed, considerations for LTV etc ( optional )

Build Section - Roadmap

  • What gaps you will fill in your product/category for next year
  • How will you fill those gaps

This Roadmap is a nearsighted roadmap rather than a time-bound roadmap.

Next 6 Milestones

In the next 6 months, or more, depending on the outcomes of POCs that the group is working on in %15.9, we will focus on releasing migrating projects by direct transfer to general availability. The scope of this undertaking is outlined below. We relate chunks of work to Jobs to Be Done. To help organise the efforts there are epics scoped to a JTBD or one of the proposed solutions for a JTBD. Exceptions are bugs (all in one epic) as well as event tracking (which serves GitLab internal use first).

Because of approaching major release of GitLab, in the next 6 months we will also work on deprecations.

Release migrating projects by direct transfer to General Availability.

JTBD: I want to easily understand the docs, estimate the effort required and assess if my organization setup meets the requirements for using the tool. - Comprehensive documentation (gitlab-org&9758)

JTBD: I want to perform imports efficiently, with little friction.

JTBD: If I make a mistake or migration fails for any reason, I want to undo and redo things efficiently.

JTBD: Should an issue occur, I want to be able to self-help.

JTBD: I want to receive high quality support: fast and that solves my problems.

JTBD: I want to understand the result of the import. - Comprehensive import results (gitlab-org&9757)

  • What was not imported
  • Why something was not imported (does it make sense to repeat, do I need to solve/fix something or contact customer service)

JTBD: I want to minimize the impact of migration to my business.

If time allows:

JTBD: I want to know how the import is progressing and how long it’s going to take.

Additionally, we need to:

Deprecations

I want to easily find info on how to move to GitLab.com.

Next 7-9 Milestones

Following successful release to general availability, we will continue to improve the capabilities of the migration tool. Often asked question is if the tool could migrate users. We will look into this, as it will be helpful for all, but especially for larger customers with many seats. Next topic will be to allow for a more granular choice of what to import.

JTBD: I want to easily migrate users between different GitLab instances while keeping their contributions - GitLab Migration - Users (gitlab-org&4616 - closed)

  • Automatic user migration
  • No preparation steps required to preserve user contributions
  • Contributions of users that are ex-employees get preserved.

JTBD: I want to perform groups and projects imports efficiently, with little friction.

Next 10-12 Milestones

Next step will be to gain parity with Congregate tool, and later superseding it, in terms of resources that are migrated.

JTBD: I want to import all group and project resources that are relevant to me.

With all that work done, we will be able to deprecate migrating projects by uploading export files:

  • Update documentation, Deprecation notice
  • Hide group and project import/export behind FFs
  • Disable FFs by default on SaaS and SM.

We will keep the deprecated method around until we are able to support off-line setups as well.

Out of scope for FY2024:

JTBD: I want to easily and efficiently migrate resources from or between offline GitLab instances.

Edited by Magdalena Frankiewicz