Get a DemoCortex AcademyWebsiteStatusLogin

Plan Migrations and Modernizations

To configure your Cortex workspace for Migrations, we recommend the following actions:

Use Cortex features to prepare for migrations

Expand the tiles below to learn about configuring Cortex features to prepare for Migrations.

Step 1: Ingest data and solve ownership 🔌

Action Items:

Before getting started on any use case, it is crucial to import your services, resources, infrastructure, and other entities, and to have clear visibility into the ownership of your entities.

Connecting your entities to Cortex establishes a single source of truth across your engineering organization. It enables the ability to track progress via Scorecards, automate Workflows, and gain insights from Eng Intelligence.

Setting ownership of entities ensures that every service and system is clearly linked to accountable teams or individuals, enabling faster incident response, reducing handoff friction, and making it possible to enforce standards consistently.

The more data you have available, the more actionable and insightful your Scorecards can be.

Relevant integrations

To focus on migrations, Cortex recommends integrating with tools that provide visibility into your inventory, ownership, on-call, and issue tracking. Make sure you have configured integrations for the following categories:

Cortex also recommends linking to runbooks and documentation for your entities, ensuring your users have access to critical information.

With your data in Cortex, you have a jumping-off point to start working on migrations.

Step 2: Configure a Scorecard and Initative for Migrations 📋

Action Item: Create a Scorecard for migrations and an associated Initiative

Scorecards automate the process of checking whether services meet criteria such as ownership and on-call coverage. You can use Scorecards to define modernization rules (e.g., entity uses supported runtime, has a Helm chart, owns SLOs).

To motivate developers to meet the rules in your Scorecard, you can configure an Initiative that asks them to complete certain rules by a specified deadline. See examples of migration Initiatives in the Initiative examples docs.

The example below walks through setting up a Scorecard that verifies entities have migrated to the latest versions for AWS RDS, Lambda, and Elasticache.

Example: Upcoming EOL for AWS Scorecard

Configure the basic details for the Scorecard

  1. In Cortex, navigate to Scorecards and click +Create Scorecard. Start with a blank Scorecard.

  2. Configure the basic details.

    • Include a name that helps your users understand the purpose of the Scorecard (e.g., Upcoming EOL for AWS) and a description.

    • Learn more about configuring basic fields for Scorecards in Create a Scorecard.

  3. Under "Apply to specific entities," narrow the scope of your Scorecard by choosing RDS, Lamba, and AWS Elasticache for Redis entity types.

Add levels and rules

  1. Under Define evaluation rules, add two levels:

    • EOL Upgrade Required

    • No Pending EOL Upgrade

  2. In the "No Pending EOL Upgrade" level, add a rule called PostgreSQL EOL Version Upgrade Completed. Include a CQL expression that verifies the entities are not on EOL versions. The following rule passes when Aurora PostgreSQL is 13.x or when Aurora MySQL is 8.x:

(jq(aws.details(), ".resources[0].engine") == "aurora-postgresql" AND jq(aws.details(), ".resources[0].engineVersion | startswith(\"13.\")") == true)
OR
(jq(aws.details(), ".resources[0].engine") == "aurora-mysql" AND jq(aws.details(), ".resources[0].engineVersion | startswith(\"8.\")") == true)

  1. Add another rule called Elasticache EOL Version Upgrade Completed. Include a CQL expression that verifies the entities are not on EOL versions. The following rule passes when Redis is 7.x or newer, Memcached is 1.6 or newer, or if no Elasticache exists for the entity:

(jq(aws.details(), ".resources[0].metadata.engine") == "redis" AND jq(aws.details(), ".resources[0].metadata.engineVersion | split(\".\")[0] | tonumber") >= 7)
OR
(jq(aws.details(), ".resources[0].metadata.engine") == "memcached" AND jq(aws.details(), ".resources[0].metadata.engineVersion | split(\".\")[0] | tonumber") >= 1 AND jq(aws.details(), ".resources[0].metadata.engineVersion | split(\".\")[1] | tonumber") >= 6)

  1. At the bottom of the page, click Save Scorecard.

Step 3: Automate processes via Workflows ⚙️

Action item: Configure Workflows

You can use Workflows to streamline and standardize processes by turning best practices into repeatable, self-service automations. This is especially valuable during modernization efforts, such as cloud or Kubernetes migrations, where consistency and speed are critical.

Check out the Cortex Academy "Migrations and Modernizations" course for a downloadable PostgreSQL upgrade prep Workflow.

Workflows to kick off a migration

You could create a Workflow that kicks off a migration or upgrade pipeline for an entity. For example, after selecting an entity and specifying the target version, the Workflow could use an HTTP Request block to trigger a CI job, like a GitHub Actions or GitLab pipeline, that handles the actual migration steps. This approach lets you standardize how migrations are initiated and monitored directly from Cortex, so teams can easily start upgrade processes without leaving Cortex.

Workflows to establish adherence to best practices

Having best practices established before a migration helps ensure a smoother migration process.

  • You can add manual approval steps in a Workflow to require sign-off from specific team members before a service is considered production-ready, ensuring accountability and providing an audit trail.

  • When Scaffolding new services, you can use templates to ensure that every new service starts with baseline standards (e.g., on-call information, runbooks, SLOs configured, and more).

Workflows based on a migration Scorecard

In a Workflow, you can use an HTTP request to get an individual entity's score or the latest scores for all entities on a migration-related Scorecard, then configure additional blocks to take actions based on the score. You can reference the output of this block in subsequent blocks, allowing you to streamline the followup actions you take based on an entity's migration status.

For example, you could create a Workflow that blocks deployment based on Scorecard scores, ensuring that a deployment is blocked if an entity has not yet migrated.

  • See an example of this Workflow in the template "Deploy to prod based on Scorecard score" in your Cortex workspace:

    See the "Deploy to prod based on Scorecard score" template in Cortex.

    • When the Workflow runs, it checks whether the entity has achieved the "Gold" level standard in the Scorecard. If it has, the deployment continues. If it has not, the Workflow automatically sends a Slack message to notify the entity owner.

    • Note that the template is configured to check a Production Readiness Scorecard; In the configuration of the HTTP Request block, you will need to configure it to point at your migration Scorecard.

Step 4: Review reports and Eng Intelligence 📈

Action Item: Review Eng Intelligence metrics and reports

Review reports for visibility into migration progress, compliance, and blockers. The Bird's Eye report gives you quick insight into where gaps are across the organization:

The bird's eye report shows a heatmap of entity progress on a Scorecard.

Use Eng Intelligence features — such as the Velocity Dashboard and Metrics Explorer — to understand your baseline metrics and for insight into how metrics are impacted during and after a migration.

Review trends in Eng Intelligence graphs and metrics.

Review trends in areas such as deployment frequency, incident response, and other indicators that are important to your organization. This helps you identify areas where teams or services are falling behind.

Migrations in action

Learn about what an ongoing migration looks like in Migrations in action.

Last updated

Was this helpful?