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)
- Docs listing requirements (prerequisites, preparation steps, recommended versions)
- Docs listing known problems and workarounds, informing about rate limits etc.
- Clear information on what project type/size are supported. - Clear and precise information on what size/type... (gitlab-org/gitlab#390092 - closed)
JTBD: I want to perform imports efficiently, with little friction.
- Pre-migration validations allow to fail fast - Allow to fail fast (gitlab-org&9769)
- The process scales to any size of groups and projects - Migration scales to large groups and projects (gitlab-org&9759 - closed)
JTBD: 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) - Retry migration if it didn't fully complete (gitlab-org&9760)
- I can clean up
JTBD: 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 - Actionable feedback to users in case of issues ... (gitlab-org&9763 - closed)
JTBD: 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. - Helpful log messages (gitlab-org&9764)
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.
- Migration doesn't pose security risks for my business - Eliminate security risks (gitlab-org&9770)
If time allows:
JTBD: I want to know how the import is progressing and how long it’s going to take.
- Progression indication in UI, via API - Show the progress of the import (gitlab-org&9765)
Additionally, we need to:
- Track number of partially completed GitLab migrations, so that we can observe it, if the percentage of partial imports increases or decreases - Sisense chart.
- Fix high severity/priority bugs.
- Possibly adjust automated testing strategy.
- Run tests on very large projects.
- Understand and plan what needs to be done in relation to comments on https://gitlab.com/gitlab-org/manage/import/discussions/-/issues/40+.
- Prepare and pass Production Readiness review.
Deprecations
I want to easily find info on how to move to GitLab.com.
- Deprecating old solutions - Deprecations 16.0 (gitlab-org&9663 - closed)
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)
- 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.
- I can easily select only what I need to import - Support efficient selection of resources to be ... (gitlab-org&9756)
- Enable to migrate subgroups with UI
- Enable to migrate only projects, without groups - Enable users to migrate only projects (gitlab-org&9755)
- UI supports fast selection
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.
- Import additional project resources - GitLab Migration - Project & Group Relations - ... (gitlab-org&9319)
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.
-
Extend migration by direct transfer to support offline environments - Direct transfer - Support for air-gapped solutions (gitlab-org&8985)
-
Automated checks against requirements - Pre-migration checks and reports (gitlab-org&9766)
-
Dry run - feedback without actually importing (“you would be importing that many”, “there are problems with this and that”) (maybe) - Create a pre-migration check report (gitlab-org/gitlab#327288)
-
Assessment of import duration