When a CircleCI alternative should be GitLab CI/CD
Choose self-managed GitLab CI/CD when source hosting and CI should consolidate on one platform that you run yourself. Keep CircleCI when hosted pipelines and minimal operations matter more than where the code and builds sit. The decision turns on three questions: where the repositories live today, how many pipelines and secrets the platform will hold, and whether your team will operate GitLab itself or pay a partner to do it. A renewal or a growing credit bill often triggers the review, but the answers to those three questions decide whether GitLab is the right destination.
If your repositories already sit on GitLab, the migration is mostly about pipelines and runners. If they sit on GitHub, Bitbucket or another forge, moving the source is a second project that can outweigh the CI savings, and a CI engine such as Woodpecker CI may fit better. Ask your platform team to list every project, pipeline, environment variable and protected deployment key, since CircleCI does not display stored variable values again and those values must be re-entered from your own records. Confirm which GitLab features your teams need, because advanced CI/CD and priority support sit in the Premium tier, while security scanning and compliance features require Ultimate, which is custom priced. Check the current figures on GitLab's pricing page before comparing totals.
Running GitLab yourself adds a standing responsibility: upgrades that pass through required upgrade stops, backups of the database and Gitaly repository storage, and runner fleets that need capacity planning. Decide who owns those tasks and whether that work is staffed in-house or delivered under a fixed-scope engagement with a partner such as DeployOpen. If builds must run with no internet access, confirm the offline installation and scanner requirements with GitLab before committing. The answer to these questions determines whether GitLab consolidates your toolchain or simply moves the operational load to your team.
Which option fits which situation
This table maps common situations to the better fit between CircleCI and GitLab CI/CD on a self-managed GitLab instance. Read each row against your repository host, your staffing and your network rules, because the right answer often depends on where your source code already lives. The main takeaway is that adopting GitLab CI/CD is most sensible when the source hosting move is already decided on its own merits.
| Scenario | Better fit | Why |
|---|---|---|
| Repositories already on GitHub or Bitbucket, with no plan to move them | CircleCI or a self-hosted engine that connects to your forge | GitLab CI/CD works best when GitLab hosts the source. Moving repositories to GitLab is a separate decision from moving CI, so keep the forge and evaluate Woodpecker CI or Jenkins for the build layer. |
| Repositories already on GitLab | GitLab CI/CD on your self-managed instance | Pipelines, runners, variables and merge request checks sit in the same platform as the code. The cost is running the GitLab instance itself, which is the larger operational commitment. |
| Source, pipelines and artifacts must stay in the organization's network | GitLab CI/CD self-managed, or a self-hosted engine such as Woodpecker CI | Hosted CircleCI keeps build artifacts for a limited period and holds deployment secrets in its own service. Confirm with GitLab and your auditor which data remains on your servers in your deployment. |
| Team has no platform staff to run stateful services | Woodpecker CI on managed or simple infrastructure, or a vendor-supported GitLab deployment | A full GitLab deployment needs PostgreSQL, Redis, Gitaly and backups kept running. Reference architectures for larger user counts add high availability components that need dedicated operators. |
| One vendor for source, CI and security scanning | GitLab CI/CD, with a tier that includes the scanning features you need | Security scanning and supply chain features are listed on the Ultimate tier, while advanced CI/CD and priority support are on Premium. Confirm the exact feature set for your tier before you decide. |
| Air-gapped network with no internet access | GitLab CI/CD, which documents offline installs, or self-hosted Jenkins | GitLab documents offline environments and separate guidance for security scanners. Confirm container image mirroring, runner images and license delivery with GitLab before committing to the design. |
Which GitLab features need a paid tier
GitLab's source is open core. Content under the ee/ directory is licensed under the GitLab Enterprise Edition license, while content outside it is available under the MIT Expat license. For a self-managed instance, that split matters less than the tier you buy, because the paid features that matter for CI/CD are gated by subscription rather than by which files you build. GitLab's pricing page lists three tiers, all available for self-managed installations: Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate, which is custom priced and needs a quote. Your cost driver is the number of users on the paid tier, so a smaller group of developers who need advanced pipeline features can be licensed separately from the wider user base if your contract allows it. Ask GitLab how seat counts, true-ups and annual billing apply to your organization.
Map each CI need to a tier before you build the business case. The pricing page places advanced CI/CD and priority support in Premium. It places application security testing, software supply chain security, vulnerability management and compliance features in Ultimate. Make a list of what your current CircleCI pipelines actually use, such as parallel test splitting, deployment approvals, security scanning stages, dependency and container scanning, or compliance pipeline controls, and check each item against the current pricing page. Do not assume a CircleCI feature has a GitLab equivalent in the same tier. Some CircleCI capabilities may be covered by open-source tooling you run yourself, and some may need Ultimate. Confirm the placement in writing with GitLab, because feature placement can change between releases and the pricing page is the reference point for the current split.
Plan for the tier decision before the pilot. Run the pilot on the tier that contains every feature your pipelines depend on, then test the gap list against it, not against the Free tier alone. Record which features are required by a pipeline and which are only nice to have, since that record tells procurement which seats need Premium or Ultimate and which can stay on Free. Revisit the list at each renewal, because a feature you do not use today can become a compliance requirement later. Also ask your DeployOpen or GitLab contact to confirm which features your self-managed version, including any air-gapped deployment, will expose.
How CircleCI capabilities map to GitLab CI/CD
This table maps CircleCI's pipeline, runner, secrets, artifact, hosting, security, upgrade and isolated-network capabilities to their GitLab CI/CD equivalents on a self-managed instance. Read each row as a question to answer in your own environment, since exact behavior depends on tier and version. The main takeaway is that GitLab combines source hosting and CI on one platform, which changes both the migration scope and the upgrade workload.
| Capability | CircleCI | GitLab CI/CD on self-managed GitLab |
|---|---|---|
| Pipeline definition | YAML config file, typically config.yml, stored in each repository | .gitlab-ci.yml at the repository root, with stages, jobs and includes |
| Runners and compute | CircleCI hosted compute, or self-hosted runners registered with CircleCI | GitLab Runner on machines, containers or Kubernetes that you run and register to the instance |
| Secrets and contexts | Project environment variables and organization contexts; values cannot be read back in the app once set | CI/CD variables at instance, group or project level, with protected and masked options. Confirm scope rules in GitLab docs |
| Artifacts and retention | Artifacts kept 30 days by default and at most 30 days, so export them before the window closes | Retention is set by the administrator on a self-managed instance. Confirm artifact expiry settings for your version |
| Source hosting | Builds repositories hosted on external forges such as GitHub or Bitbucket | Repositories, merge requests, issues and CI in one platform, so one system to back up and upgrade |
| Security scanning | Scanning is added through orbs or third-party tools you connect. Confirm what your plan includes | Application security testing and supply chain features are listed for the top, custom-priced tier on GitLab's pricing page |
| Upgrades | CircleCI Server 4.10 installs into your Kubernetes cluster. Confirm the upgrade path with the vendor | Yearly major release, monthly minor release on the third Thursday, and patch releases twice a month, with required upgrade stops |
| Air-gapped operation | CircleCI Server path for isolated networks, with a vendor-provided image registry login and Kubernetes-based dependencies | Documented offline installation, with separate guidance for security scanners and GitLab Duo Self-Hosted |
What changes in the pipeline file and the runners
CircleCI defines a pipeline in .circleci/config.yml, where jobs run inside executors (Docker images, machine images or macOS) and workflows decide which jobs run, in what order and on which branches. Reusable behavior often comes from orbs, which bundle commands, jobs and executors. Contexts hold shared environment variables and are attached to workflows. Runners are either CircleCI's hosted compute, sized with resource classes, or self-hosted runners that you operate.
- Pipeline file:
config.ymljobs and workflows are the parts that carry over most directly to GitLab stages and jobs, once you map each workflow to a set of stages. - Orbs: Orb commands and jobs usually need redesign as plain script steps, included templates or a shared CI component owned by your team.
- Contexts: Contexts are the closest match to GitLab group-level variables, but protection rules, branch restrictions and who can edit them must be re-declared in GitLab.
- Resource classes: These size hosted compute. On GitLab you choose machine size through the runner you register or the autoscaling settings, so each job needs a sizing decision.
- Runners: Self-hosted CircleCI runners and GitLab Runner are operated by you in both cases, but their registration, tags and concurrency settings differ.
Confirm with your CircleCI admin which orbs, contexts and self-hosted runners are in active use before estimating the rewrite.
GitLab CI/CD reads .gitlab-ci.yml at the repository root. Pipelines are built from stages, which run in order, and jobs, which run in parallel within a stage unless dependencies or needs change that. Each job selects a runner through tags. GitLab Runner executes jobs using an executor such as Docker, Kubernetes, shell or others listed in the runner documentation. Variables can be set at instance, group or project level and marked protected or masked.
- Stages and jobs: Jobs map cleanly to GitLab jobs, while workflow ordering maps to
stagesandneeds, which allow a job to start before its whole stage finishes. - Executors: CircleCI Docker executors correspond to the GitLab Runner Docker or Kubernetes executors, but image pull policy, privileged mode and cache volumes need explicit configuration.
- Runner tags: Tags replace resource classes and pool selection. Use them to direct heavy jobs to larger runners and to keep production deployments on dedicated runners.
- Group and project variables: Group variables replace contexts. Protected and masked flags control exposure, and they do not carry over automatically from CircleCI.
- Concurrency: Runner concurrency and job limits are set on the runner and instance, not per plan credit, so capacity planning moves to your team.
Check the GitLab Runner and CI/CD documentation for your installed version before you finalize runner tags and executor choices.
The two platforms do not share a scheduling model, so a line-by-line translation of concurrency and triggers will produce a pipeline that behaves differently. CircleCI charges by credits and applies plan-level concurrency, while GitLab concurrency depends on how many runners and job slots you provision. The CircleCI Preview that runs existing GitHub Actions workflow files does not apply to GitLab, so the pipeline must be rewritten in .gitlab-ci.yml.
- Triggers: CircleCI workflow filters on branches and tags need to be re-expressed with GitLab
rulesorworkflow:rules. - Scheduling: Queueing behaves differently when runners are shared, so jobs that previously waited for a hosted slot may start sooner or later on your own runners.
- Caching and artifacts: Retention and cache keys differ, so artifact expiry should be set explicitly in the new pipeline.
- Secrets: Values set in CircleCI cannot be read back, so they must be re-entered in GitLab from their source systems.
- Migration path: Run both pipelines in parallel for a defined period before you disable the CircleCI config.
Ask your implementation partner to produce a job-by-job mapping and a runner sizing plan before the rewrite starts.
Where the code, secrets and build data sit after the move
Moving from CircleCI to a self-managed GitLab instance changes where repositories, pipeline secrets, build artifacts and audit evidence live. The cards below cover the decisions that follow from that change, from the secret re-entry work to the compliance evidence your own team must produce.
Why teams move build secrets in-house
In its January 4, 2023 incident report, CircleCI told all customers to rotate secrets after an attacker exfiltrated customer environment variables, tokens and keys, along with the encryption keys needed to read them. That report describes one vendor's incident. It does not show that other customers were affected in the same way, but it does show why many teams want deployment secrets held inside their own network. Check the report and your own exposure before you set the rotation scope.
Re-entering and rotating CI secrets
CI secrets generally cannot be exported. CircleCI states that environment variable values are not readable in its app after they are set, and GitHub's API returns secret names without values. Plan to re-enter each value into GitLab CI/CD variables, scope them by protected and masked settings, and rotate every credential the pipelines used, not only the ones you can recover. Build an inventory of projects, contexts and variables before cutover.
Choosing a GitLab installation method
GitLab documents five installation methods: the Linux package, the Helm chart, the GitLab Operator, Docker and source. The Linux package bundles PostgreSQL, Redis and Sidekiq, and GitLab describes it as the most mature and scalable method. Your team's Kubernetes standards and operating model should drive the choice. Confirm which method the GitLab version you select supports for your environment before you commit to a platform.
Keeping stateful services out of Kubernetes
GitLab's reference architecture documentation states that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid pattern runs stateless components on Kubernetes and places stateful services on virtual machines or managed services. This affects who operates the database and backups, and it changes the capacity plan. Ask your platform team to confirm the pattern and the storage they will provide before sizing the instance.
Integrating authentication and authorization
CI access depends on who can view, edit and run pipelines, and on which runners can deploy to which environments. Map your existing identity provider, group structure and role model into GitLab before users log in, and decide how service accounts and deploy tokens are issued and reviewed. GitLab's authentication and authorization documentation covers the supported integrations. Confirm which sign-in methods your tier supports, because some features depend on the license level.
Compliance evidence your team must produce
DeployOpen prepares controls, configurations and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Your organization must still produce evidence such as access reviews, secret rotation records, backup and restore test results, and change logs from pipelines. Agree with your auditor early which artifacts they will accept, and confirm how long your retention policy requires them to be kept.
What the cost of ownership is made of on each side
CircleCI charges through plans, credits and concurrency, or through a CircleCI Server contract, while a self-managed GitLab shifts cost onto subscriptions, infrastructure and your team's operating time. Each card below names one component, whether it recurs, and what moves it up or down.
CircleCI plan and credit usage
CircleCI bills plan fees alongside credits that are consumed by build compute, so the monthly total moves with how many minutes your pipelines run and which resource classes they select. Credits recur every billing period, and heavier resource classes or parallel test splitting consume them faster. Ask the vendor how credits convert to compute for each resource class you use, and which overage rates apply once included credits run out.
CircleCI concurrency and resource classes
Concurrency limits and resource class choices decide how many jobs run at once and how long a queue forms behind a release. Raising concurrency or moving jobs to larger resource classes is a recurring cost that grows with team size and build volume. Check the concurrency tier in your plan before a quote, because a queue that delays deployments has a cost even when the invoice does not show it.
CircleCI Server contract
Where CIRCLECI Server is required for CI inside your own network, the cost is a vendor contract plus the Kubernetes, MongoDB, PostgreSQL, RabbitMQ, Redis, Vault and object storage it needs to run. The contract is recurring and its price is not published, so request it in writing along with the infrastructure and operator time the vendor expects you to carry. Server 4.10 installs into your Kubernetes cluster, which means the capacity charge is yours even when the license is not.
GitLab subscription tier per user
GitLab Free costs 0 dollars, and the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced, and all three tiers available for self-managed installations. Premium is the tier that adds advanced CI/CD and priority support, so most teams compare Free against Premium on the features they need. Recurring cost scales with the number of users who need paid features, so confirm which users must hold a seat and whether the quote is annual.
GitLab servers, Kubernetes and runner capacity
A self-managed GitLab needs compute for the instance and separate capacity for GitLab Runner, and GitLab's reference architectures scale from 1,000 users to 50,000 users. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so plan VMs or managed services for them and use Kubernetes for stateless parts. Recurring infrastructure cost depends on user count, pipeline volume and whether you add high availability, so size it against the reference architecture that matches your headcount.
High availability for 3,000 users or more
GitLab generally recommends a high availability strategy for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. This is a recurring infrastructure and operations cost because each component needs its own nodes, monitoring and failover testing. Ask whether your user count and availability target require this design, and which parts you would run yourself versus on managed services.
Storage for artifacts and backups
Unlike hosted CI, a self-managed GitLab keeps artifacts, repositories and backups on storage you provision, so retention is a decision you make rather than a vendor default. Storage grows with build volume, artifact retention rules and how many backup generations you keep, and it recurs each month. Set artifact expiry and backup retention in writing before you request a quote, and confirm the restore procedure covers both the database and repositories.
Upgrades through required upgrade stops
GitLab ships a major release yearly and a minor release monthly, and upgrades must pass through required upgrade stops at versions such as 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Each stop is a planned, recurring staff task with testing, a backup and a rollback plan, and it is the largest ongoing labor item on the GitLab side. GitLab's maintenance policy backports bug fixes only to the current stable release, so budget for keeping pace rather than waiting. Ask for the upgrade effort in your written scope.
Support and operator staff time
Premium includes priority support, but the staff who run GitLab, Runner fleets, backups and upgrades are an internal cost that recurs every year. Their time is driven by how many instances, runners and integrations you run, and by how quickly you need incidents resolved. On the CircleCI side, support is included in the plan tier, so compare the support level you actually receive on each side and the people who will cover on-call.
What a move from CircleCI to GitLab CI/CD involves
The sequence turns CircleCI pipelines, artifacts and secrets into a self-managed GitLab instance with runners that your team operates, and ends with CircleCI retired after the new pipelines have proven themselves.
Inventory pipelines, orbs and contexts
Your platform or DevOps team lists every CircleCI project, its config.yml, the orbs it calls, the contexts it reads, and the deployment targets it reaches. Each pipeline is tagged by owner and by whether it deploys to production, so the order of migration is clear. The step is done when every project has a row in a shared inventory that an engineering lead has reviewed, and each orb has a known replacement, such as a script, a template or a shared include.
Decide where repositories will live
Leadership and the platform team decide whether source hosting moves to GitLab along with CI, or whether repositories stay on GitHub, Bitbucket or another forge while GitLab runs only the pipelines. GitLab CI/CD works with repositories it hosts directly, and moving code is a separate project with its own access and history questions. The output is a written decision, approved by the security and engineering owners, that sets which webhooks and mirrors the later steps must handle.
Stand up a self-managed GitLab instance and runners
Your infrastructure team installs a self-managed GitLab instance inside your own cloud account, data center or air-gapped network, using an installation method that matches your operating model, and registers GitLab Runner machines or Kubernetes runners for build capacity. Backup, identity integration and offline access are configured here, not later. DeployOpen can plan and implement this as a fixed-scope engagement if you want outside help. The step is done when a test project builds, stores its artifacts and passes a backup and restore check in your environment.
Rewrite configs and run pipelines in parallel
Engineers translate each config.yml into .gitlab-ci.yml, mapping workflows to stages and jobs, Docker executors to runner images, and orb steps to scripts or includes. Both systems run the same commit for a set period so results can be compared, with differences in test counts, cache behavior and timing investigated by the owning team. The step closes when each migrated pipeline gives the same pass or fail result on the same commits across that comparison window.
Export artifacts before the 30-day window closes
Before CircleCI removes them, teams download the build artifacts they need to keep, such as release packages, test reports and signed images, through CircleCI's API or the app. CircleCI sets 30 days as both the default and the maximum retention period, so this export must be scheduled as a dated task rather than left for later. Records of which artifacts were exported, and where they were placed in your storage, are kept as the evidence for this step.
Re-enter and rotate secrets
CircleCI does not show environment variable values after they are set, so the values cannot be copied across. Owners of each deployment credential, cloud key and registry token generate new values where possible, enter them into GitLab CI/CD variables or a secrets manager with protected and masked settings, and revoke the old ones. CircleCI's January 4, 2023 incident report told customers to rotate secrets after an exfiltration, which is a reason to treat this as a full rotation rather than a copy. The step is done when a security reviewer confirms that every old credential is revoked and no pipeline depends on a value that only CircleCI holds.
Cut over webhooks and deployment targets
The platform team switches repository webhooks, status checks, branch protection rules and deployment targets from CircleCI to GitLab, one team at a time. Deployment environments, approval rules and any notifications that CircleCI sent are re-created and tested in a staging environment first. Each cutover is recorded with the date, the owning team and the rollback path. The step is done when production deployments run only from GitLab and no CircleCI webhook still fires for those repositories.
Retire CircleCI after verification
After the new pipelines have run through a verification period agreed with the engineering and security leads, CircleCI projects are disabled, the organization's CircleCI access is removed, and the final configuration and artifact exports are archived with the rest of the migration records. Your team confirms the closure in writing, and any contract or plan changes are handled with CircleCI separately. The migration is complete when no production path depends on CircleCI and the archive can be used for audit or incident review.
Questions buyers ask before a CircleCI to GitLab move
How much does a CircleCI to GitLab move cost?
The cost depends on the scope agreed in writing, and no single figure applies to every team. The main cost drivers are the number of pipelines, how many CircleCI orbs must be replaced with GitLab CI/CD templates or scripts, how many environment variables and contexts must be re-created, the volume of build artifacts to export, and how many runner designs you need. Costs fall into one-time work (assessment, pipeline conversion, secret re-creation, testing, cutover) and recurring work (GitLab subscription, runner compute, storage, upgrades and backups). Ask any quote to separate these lines and to state which GitLab tier it assumes. GitLab's pricing page lists Free at 0 US dollars and Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced, so the subscription line depends on your tier and user count.
How long does a CircleCI to GitLab migration take?
The timeline is set by the agreed scope, the number of pipelines, and how much parallel running your release process requires. Each pipeline needs its config rewritten in .gitlab-ci.yml, its runners set up, and its test runs compared against the CircleCI results before cutover. Teams that keep CircleCI running alongside GitLab for a period can switch projects gradually, which usually takes longer but reduces release risk. DeployOpen issues a written scope and timeline before work starts for fixed-scope engagements. Ask for the timeline to list pipeline groups, parallel-run length, and the cutover order.
Can our own team migrate from CircleCI to GitLab without outside help?
A small set of straightforward pipelines can often be moved in-house by a team with working GitLab experience. The skills that matter are GitLab CI/CD syntax in .gitlab-ci.yml, GitLab Runner installation and tagging, container image build and registry work, secret management in GitLab, and enough Linux and Kubernetes or VM administration to run the runners and the GitLab instance. Larger estates with many orbs, shared contexts, custom executors, or strict audit requirements usually benefit from outside help. Confirm your team's skills against your own pipeline inventory before deciding.
Do we need GitLab Premium or Ultimate to run our pipelines?
It depends on which CI/CD and security features your pipelines use, and this should be confirmed against the current GitLab pricing page before you buy. According to that page, Premium includes advanced CI/CD and priority support, while Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. Core pipeline execution, runners and the .gitlab-ci.yml workflow are the starting point, and many teams begin on a lower tier and add features as needs are confirmed. Ask your GitLab representative to map each feature your pipelines rely on to a tier in writing.
Does self-managed GitLab work in an air-gapped network?
GitLab documents running self-managed instances in offline, air-gapped environments, and it publishes separate guidance for running its security scanners and GitLab Duo Self-Hosted without internet access. Air-gapped CI also needs container images, package mirrors and runner dependencies available inside the network, so the offline setup must cover those as well. Read GitLab's offline environments guidance for the exact steps, and confirm with GitLab which features your network can run offline. DeployOpen can implement and document the offline setup in your own environment as part of a fixed-scope engagement.
What happens to our CircleCI secrets during the move?
CircleCI does not show environment variable values after they are set, so the values cannot be copied out of the app and must be re-created from their original sources. CircleCI also stated in its January 4, 2023 incident report that customers should rotate secrets after an attacker exfiltrated environment variables, tokens and keys. A migration should treat every secret as something to rotate and re-issue: create new values in GitLab CI/CD variables or a dedicated secrets manager, scope them to protected branches and environments, and revoke the old CircleCI credentials after cutover is verified. Ask for an inventory of secrets by owner and purpose before work starts.
What ongoing work does a self-managed GitLab need after go-live?
Running GitLab yourself means recurring operational work: upgrades, backups, restore tests, runner maintenance and security patching. GitLab ships a major release yearly, a minor release on the third Thursday of each month, and patch releases twice a month, and it requires upgrades to pass through required upgrade stops such as 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11. Bug fixes reach only the current stable release, so falling behind leaves you without them. DeployOpen plans, upgrades, backs up, documents and supports self-hosted platforms, and ongoing support, upgrades and continuous testing are available as retainers. Ask for the retainer scope in writing and confirm the backup and restore procedure against GitLab's backup and restore documentation.
How DeployOpen helps evaluate and move to GitLab CI/CD
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including a self-managed GitLab instance. For CircleCI vs GitLab CI/CD, we start by agreeing in writing what moves, what stays and how the cutover is checked before any work begins.
How we scope
- Inventory CircleCI projects, orbs, contexts and runner usage to decide what maps to GitLab CI/CD
- Confirm which GitLab tier your required CI and security features need before design starts
- Agree in writing which pipelines, runners and secrets move, and which stay on CircleCI during a parallel run
- Engagements are fixed-scope, with deliverables and timelines confirmed in the written scope
How we build
- Convert .circleci/config.yml pipelines into .gitlab-ci.yml files and test each job against a non-production project
- Install and configure GitLab Runner on infrastructure you control, sized to the concurrency your projects need
- Re-create environment variables in GitLab by hand, since CircleCI does not display stored values
- Run security testing on the pipelines, runners and GitLab instance, and document the results for your review
How we hand over
- Deliver runbooks covering pipeline ownership, runner operations, backups and GitLab upgrade stops
- Provide a record of the secret rotation performed after the move, with a list of which credentials changed
- Document the parallel-run comparison so your team can confirm build results match before cutover
- Hand over configuration, documentation and access in a form your own staff can maintain
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover GitLab patch and minor release upgrades and runner version updates
- Ask whether a retainer covers backup restore testing and security re-testing after major changes
- Request a written quote that follows from the agreed scope, since DeployOpen does not publish a price list
