diff --git a/content/actions/learn-github-actions/index.md b/content/actions/learn-github-actions/index.md
index 9329c5bac2e2..8bc97d038f8e 100644
--- a/content/actions/learn-github-actions/index.md
+++ b/content/actions/learn-github-actions/index.md
@@ -37,5 +37,6 @@ versions:
{% link_with_intro /sharing-workflows-with-your-organization %}
{% link_with_intro /security-hardening-for-github-actions %}
{% link_with_intro /migrating-from-circleci-to-github-actions %}
+{% link_with_intro /migrating-from-gitlab-cicd-to-github-actions %}
{% link_with_intro /migrating-from-azure-pipelines-to-github-actions %}
{% link_with_intro /migrating-from-jenkins-to-github-actions %}
diff --git a/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
new file mode 100644
index 000000000000..873144e8fe04
--- /dev/null
+++ b/content/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions.md
@@ -0,0 +1,476 @@
+---
+title: Migrating from GitLab CI/CD to GitHub Actions
+intro: '{% data variables.product.prodname_actions %} and GitLab CI/CD share several configuration similarities, which makes migrating to {% data variables.product.prodname_actions %} relatively straightforward.'
+versions:
+ free-pro-team: '*'
+ enterprise-server: '>=2.22'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+### Introduction
+
+GitLab CI/CD and {% data variables.product.prodname_actions %} both allow you to create workflows that automatically build, test, publish, release, and deploy code. GitLab CI/CD and {% data variables.product.prodname_actions %} share some similarities in workflow configuration:
+
+- Workflow configuration files are written in YAML and are stored in the code's repository.
+- Workflows include one or more jobs.
+- Jobs include one or more steps or individual commands.
+- Jobs can run on either managed or self-hosted machines.
+
+There are a few differences, and this guide will show you the important differences so that you can migrate your workflow to {% data variables.product.prodname_actions %}.
+
+### Jobs
+
+Jobs in GitLab CI/CD are very similar to jobs in {% data variables.product.prodname_actions %}. In both systems, jobs have the following characteristics:
+
+* Jobs contain a series of steps or scripts that run sequentially.
+* Jobs can run on separate machines or in separate containers.
+* Jobs run in parallel by default, but can be configured to run sequentially.
+
+You can run a script or a shell command in a job. In GitLab CI/CD, script steps are specified using the `script` key. In {% data variables.product.prodname_actions %}, all scripts are specified using the `run` key.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+job1:
+ variables:
+ GIT_CHECKOUT: "true"
+ script:
+ - echo "Run your script here"
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ job1:
+ steps:
+ - uses: actions/checkout@v2
+ - run: echo "Run your script here"
+```
+{% endraw %}
+ |
+
+
+
+### Runners
+
+Runners are machines on which the jobs run. Both GitLab CI/CD and {% data variables.product.prodname_actions %} offer managed and self-hosted variants of runners. In GitLab CI/CD, `tags` are used to run jobs on different platforms, while in {% data variables.product.prodname_actions %} it is done with the `runs-on` key.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+windows_job:
+ tags:
+ - windows
+ script:
+ - echo Hello, %USERNAME%!
+
+linux_job:
+ tags:
+ - linux
+ script:
+ - echo "Hello, $USER!"
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+windows_job:
+ runs-on : windows-latest
+ steps:
+ - run: echo Hello, %USERNAME%!
+
+linux_job:
+ runs-on: ubuntu-latest
+ steps:
+ - run: echo "Hello, $USER!"
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)."
+
+### Docker images
+
+Both GitLab CI/CD and {% data variables.product.prodname_actions %} support running jobs in a Docker image. In GitLab CI/CD, Docker images are defined with a `image` key, while in {% data variables.product.prodname_actions %} it is done with the `container` key.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+my_job:
+ image: node:10.16-jessie
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ my_job:
+ container: node:10.16-jessie
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer)."
+
+### Condition and expression syntax
+
+GitLab CI/CD uses `rules` to determine if a job will run for a specific condition. {% data variables.product.prodname_actions %} uses the `if` keyword to prevent a job from running unless a condition is met.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+deploy_prod:
+ stage: deploy
+ script:
+ - echo "Deply to production server"
+ rules:
+ - if: '$CI_COMMIT_BRANCH == "master"'
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ deploy_prod:
+ if: contains( github.ref, 'master')
+ runs-on: ubuntu-latest
+ steps:
+ - run: echo "Deply to production server"
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
+
+### Dependencies between Jobs
+
+Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to set dependencies for a job. In both systems, jobs run in parallel by default, but job dependencies in {% data variables.product.prodname_actions %} can be specified explicitly with the `needs` key. GitLab CI/CD also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in {% data variables.product.prodname_actions %} with the `needs` key.
+
+Below is an example of the syntax for each system. The workflows start with two jobs named `build_a` and `build_b` running in parallel, and when those jobs complete, another job called `test_ab` will run. Finally, when `test_ab` completes, the `deploy_ab` job will run.
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+stages:
+ - build
+ - test
+ - deploy
+
+build_a:
+ stage: build
+ script:
+ - echo "This job will run first."
+
+build_b:
+ stage: build
+ script:
+ - echo "This job will run first, in parallel with build_a."
+
+test_ab:
+ stage: test
+ script:
+ - echo "This job will run after build_a and build_b have finished."
+
+deploy_ab:
+ stage: deploy
+ script:
+ - echo "This job will run after test_ab is complete"
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ build_a:
+ runs-on: ubuntu-latest
+ steps:
+ - run: echo "This job will be run first."
+
+ build_b:
+ runs-on: ubuntu-latest
+ steps:
+ - run: echo "This job will be run first, in parallel with build_a"
+
+ test_ab:
+ runs-on: ubuntu-latest
+ needs: [build_a,build_b]
+ steps:
+ - run: echo "This job will run after build_a and build_b have finished"
+
+ deploy_ab:
+ runs-on: ubuntu-latest
+ needs: [test_ab]
+ steps:
+ - run: echo "This job will run after test_ab is complete"
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)."
+
+### Scheduling workflows
+
+Both GitLab CI/CD and {% data variables.product.prodname_actions %} allow you to run workflows at a specific interval. In GitLab CI/CD, pipeline schedules are configured with the UI, while in {% data variables.product.prodname_actions %} you can trigger a workflow on a scheduled interval with the "on" key.
+
+For more information, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#scheduled-events)."
+
+### Variables and secrets
+
+GitLab CI/CD and {% data variables.product.prodname_actions %} support setting environment variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI.
+
+For more information, see "[Environment variables](/actions/reference/environment-variables)" and "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+
+### Caching
+
+GitLab CI/CD and {% data variables.product.prodname_actions %} provide a method in the configuration file to manually cache workflow files.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+image: node:latest
+
+cache:
+ key: $CI_COMMIT_REF_SLUG
+ paths:
+ - .npm/
+
+before_script:
+ - npm ci --cache .npm --prefer-offline
+
+test_async:
+ script:
+ - node ./specs/start.js ./specs/async.spec.js
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ test_async:
+ - name: Cache node modules
+ uses: actions/cache@v2
+ with:
+ path: ~/.npm
+ key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
+ restore-keys: v1-npm-deps-
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)."
+
+### Artifacts
+
+Both GitLab CI/CD and {% data variables.product.prodname_actions %} can upload files and directories created by a job as artifacts. In {% data variables.product.prodname_actions %}, artifacts can be used to persist data across multiple jobs.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+script:
+artifacts:
+ paths:
+ - math-homework.txt
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+- name: Upload math result for job 1
+ uses: actions/upload-artifact@v2
+ with:
+ name: homework
+ path: math-homework.txt
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[Storing workflow data as artifacts](/actions/guides/storing-workflow-data-as-artifacts)."
+
+### Databases and service containers
+
+Both systems enable you to include additional containers for databases, caching, or other dependencies.
+
+In GitLab CI/CD, a container for the job is specified with the `image` key, while {% data variables.product.prodname_actions %} uses the `container` key. In both systems, additional service containers are specified with the `services` key.
+
+Below is an example of the syntax for each system:
+
+
+
+
+GitLab CI/CD
+ |
+
+{% data variables.product.prodname_actions %}
+ |
+
+
+
+{% raw %}
+```yaml
+container-job:
+ variables:
+ POSTGRES_PASSWORD: postgres
+ # The hostname used to communicate with the
+ # PostgreSQL service container
+ POSTGRES_HOST: postgres
+ # The default PostgreSQL port
+ POSTGRES_PORT: 5432
+ image: node:10.18-jessie
+ services:
+ - postgres
+ script:
+ # Performs a clean installation of all dependencies
+ # in the `package.json` file
+ - npm ci
+ # Runs a script that creates a PostgreSQL client,
+ # populates the client with data, and retrieves data
+ - node client.js
+ tags:
+ - docker
+```
+{% endraw %}
+ |
+
+{% raw %}
+```yaml
+jobs:
+ container-job:
+ runs-on: ubuntu-latest
+ container: node:10.18-jessie
+
+ services:
+ postgres:
+ image: postgres
+ env:
+ POSTGRES_PASSWORD: postgres
+
+ steps:
+ - name: Check out repository code
+ uses: actions/checkout@v2
+
+ # Performs a clean installation of all dependencies
+ # in the `package.json` file
+ - name: Install dependencies
+ run: npm ci
+
+ - name: Connect to PostgreSQL
+ # Runs a script that creates a PostgreSQL client,
+ # populates the client with data, and retrieves data
+ run: node client.js
+ env:
+ # The hostname used to communicate with the
+ # PostgreSQL service container
+ POSTGRES_HOST: postgres
+ # The default PostgreSQL port
+ POSTGRES_PORT: 5432
+```
+{% endraw %}
+ |
+
+
+
+For more information, see "[About service containers](/actions/guides/about-service-containers)."
diff --git a/content/index.md b/content/index.md
index ba3d56935da4..1800e3661d03 100644
--- a/content/index.md
+++ b/content/index.md
@@ -13,3 +13,4 @@ popularLinks:
- /github/working-with-github-pages
versions: '*'
---
+