This document describes how you define the scope of your migration to deploy
RIOT Live Migration to migrate to Redis Enterprise Cloud in a production environment. Database architects, DevOps and SRE teams, or Network
administrators can use this architecture to offer near-zero downtime migrations
to their teams. This document assumes that you're familiar with using the
Google Cloud CLI and Compute Engine.
To define the scope of your migration, you complete the following steps:
Assess the source environment.
Build an inventory of your source instances.
Identify and document the migration scope and affordable downtime.
Assess your deployment and administration process.
Assess the source environment
To assess your source environment, you determine the requirements and
dependencies of the resources that you want to migrate from Redis OSS, AWS
ElastiCache, and Azure Cache for Redis to a fully-managed Redis Enterprise Cloud
instance in Google Cloud.
The assessment phase consists of the following tasks:
Build a comprehensive inventory of Redis-compatible workloads.
Perform data sizing and Redis Cluster sizing:
If you're using AWS ElastiCache, you can extract your database
metrics by using the Redis tool
ECstats.
If you're using Azure Cache for Redis, you can extract raw usage
data for your Redis instances by using the
acrp2acre
tool.
Decide on the order and priority of the workloads that you want to
migrate. Create different
subscriptions
to consolidate databases with similar purposes such as development or test,
staging, and production.
Build an inventory of your source instances
To define the scope of your migration, you create an inventory of your source
instances from Redis OSS, AWS ElastiCache, and Azure Cache for Redis. The goal
of this step is to collect information about each database, such as memory
limit, IOPS, and durability requirements.
Identify and document the migration scope and affordable downtime
To have a successful migration, you need to have a migration scope in
place. To scope your migration, you document essential information that
influences your migration strategy and tooling. By this stage of the assessment,
you can answer the following questions:
Are your databases larger than 250GB? If so, you will receive a lower
total cost of ownership if
auto-tiering
is enabled.
Where are the databases located (regions and zones) and what is their
proximity to applications?
How often does the data change?
Many components of this effort are already described in the preceding
section "Build an inventory of your source instances." However, there are other
aspects that you need to consider in this step, like documenting the
scalability, durability, and security requirements and constraints that need to
be upheld. We recommend that you review the
Redis Trust Center
for industry and compliance certifications, and discuss them with your business
owners and legal team if necessary.
You should also define a thorough migration scope. You can use the output from
tools like
ECstats
and
acrp2acre
to define the sizing requirements for your Redis Enterprise Cloud instances in
Google Cloud. Review the attributes of each database instance, such as
scalability, and security requirements. If the database size is greater than
250 GB, we recommend that you use auto-tiering. We also recommend that you
group databases with similar characteristics and security profiles into a single
subscription.
Doing so will help ensure that your database migration doesn't affect your
existing SLA and business operations.
Assess your deployment and administration process
To ensure that there aren't any unnecessary interruptions to your production
environment, we recommend that you assess the operational and deployment
processes of your database. The assessment should help you to determine how your
databases need to be adapted to facilitate a successful migration.
Assess how you define and enforce
security policies
for your database instance to control access to your database.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-01-29 UTC."],[[["\u003cp\u003eThis document outlines the steps for migrating from Redis OSS, AWS ElastiCache, and Azure Cache for Redis to Redis Enterprise Cloud in a production environment with near-zero downtime, using RIOT Live Migration.\u003c/p\u003e\n"],["\u003cp\u003eThe migration process involves assessing the source environment, building an inventory of source instances, defining the migration scope and downtime allowance, and evaluating the existing deployment and administration processes.\u003c/p\u003e\n"],["\u003cp\u003eAssessing the source environment includes inventorying workloads, data and cluster sizing, reviewing networking requirements, calculating total cost of ownership, and determining workload migration priority.\u003c/p\u003e\n"],["\u003cp\u003eDefining the migration scope involves documenting database locations, data change frequency, scalability, durability, and security requirements, as well as leveraging tools like ECstats and acrp2acre to determine sizing.\u003c/p\u003e\n"],["\u003cp\u003eEvaluating the deployment process involves assessing the definition of security policies and monitoring and alerting requirements, as well as collecting metrics by using Prometheus and Grafana integration.\u003c/p\u003e\n"]]],[],null,["# Define the scope of your migration to Redis Enterprise Cloud\n\nBy: Gilbert Lau, Principal Cloud Architect, [Redis](https://redis.io/)\n\nThis document describes how you define the scope of your migration to deploy\n[RIOT Live Migration to migrate to Redis Enterprise Cloud](/architecture/partners/riot-live-migration-redis-enterprise-cloud) in a production environment. Database architects, DevOps and SRE teams, or Network\nadministrators can use this architecture to offer near-zero downtime migrations\nto their teams. This document assumes that you're familiar with using the\nGoogle Cloud CLI and Compute Engine.\n\nTo define the scope of your migration, you complete the following steps:\n\n1. Assess the source environment.\n2. Build an inventory of your source instances.\n3. Identify and document the migration scope and affordable downtime.\n4. Assess your deployment and administration process.\n\nAssess the source environment\n-----------------------------\n\nTo assess your source environment, you determine the requirements and\ndependencies of the resources that you want to migrate from Redis OSS, AWS\nElastiCache, and Azure Cache for Redis to a fully-managed Redis Enterprise Cloud\ninstance in Google Cloud.\n\nThe assessment phase consists of the following tasks:\n\n1. Build a comprehensive inventory of Redis-compatible workloads.\n2. Perform data sizing and Redis Cluster sizing:\n - If you're using AWS ElastiCache, you can extract your database metrics by using the Redis tool [ECstats](https://github.com/Redislabs-Solution-Architects/ecstats2).\n - If you're using Azure Cache for Redis, you can extract raw usage data for your Redis instances by using the [acrp2acre](https://github.com/Redislabs-Solution-Architects/acrp2acre) tool.\n3. Review networking requirements such as [VPC peering](https://docs.redis.com/latest/rc/security/vpc-peering/) or [Private service connect](https://docs.redis.com/latest/rc/security/private-service-connect/).\n4. Calculate the total cost of ownership (TCO) of the target environment by visiting the [Redis Enterprise Cloud Pricing page](https://redis.com/cloud/pricing/).\n5. Decide on the order and priority of the workloads that you want to migrate. Create different [subscriptions](https://docs.redis.com/latest/rc/subscriptions/#flexible-plans) to consolidate databases with similar purposes such as development or test, staging, and production.\n\nBuild an inventory of your source instances\n-------------------------------------------\n\nTo define the scope of your migration, you create an inventory of your source\ninstances from Redis OSS, AWS ElastiCache, and Azure Cache for Redis. The goal\nof this step is to collect information about each database, such as memory\nlimit, IOPS, and durability requirements.\n\n- Generic properties at the [subscription level](https://docs.redis.com/latest/rc/subscriptions/#flexible-plans):\n - The region of your subscription\n - Active-Active geo distribution\n - Auto-tiering (receive lower total cost of ownership if memory limit is over 250GB or more)\n- Configurations for each database:\n - Memory limit and throughput (operations per second)\n - High availability\n - Durability requirements\n - [Advanced capabilities](https://docs.redis.com/latest/rc/databases/create-database/#flexible-and-annual-module-options) such as search, JSON, time series, and probabilistic for each database\n - Connection information including port, user, and other [security options](https://docs.redis.com/latest/rc/databases/create-database/#security-section)\n- Requirements and constraints:\n - Recovery point objective (RPO) and recovery time objective (RTO)\n - Service level agreements (SLAs)\n - Regulatory and compliance requirements (see the [Redis Customer Trust Center](https://redis.com/company/compliance-and-privacy/))\n - Authentication and security requirements\n\nIdentify and document the migration scope and affordable downtime\n-----------------------------------------------------------------\n\nTo have a successful migration, you need to have a migration scope in\nplace. To scope your migration, you document essential information that\ninfluences your migration strategy and tooling. By this stage of the assessment,\nyou can answer the following questions:\n\n- Are your databases larger than 250GB? If so, you will receive a lower total cost of ownership if [auto-tiering](https://docs.redis.com/latest/rs/databases/auto-tiering/) is enabled.\n- Where are the databases located (regions and zones) and what is their proximity to applications?\n- How often does the data change?\n\nMany components of this effort are already described in the preceding\nsection \"Build an inventory of your source instances.\" However, there are other\naspects that you need to consider in this step, like documenting the\nscalability, durability, and security requirements and constraints that need to\nbe upheld. We recommend that you review the\n[Redis Trust Center](https://trust.redis.com/)\nfor industry and compliance certifications, and discuss them with your business\nowners and legal team if necessary.\n\nYou should also define a thorough migration scope. You can use the output from\ntools like\n[ECstats](https://github.com/Redislabs-Solution-Architects/ecstats2)\nand\n[acrp2acre](https://github.com/Redislabs-Solution-Architects/acrp2acre)\nto define the sizing requirements for your Redis Enterprise Cloud instances in\nGoogle Cloud. Review the attributes of each database instance, such as\nscalability, and security requirements. If the database size is greater than\n250 GB, we recommend that you use auto-tiering. We also recommend that you\ngroup databases with similar characteristics and security profiles into a single\n[subscription](https://docs.redis.com/latest/rc/subscriptions/#flexible-plans).\nDoing so will help ensure that your database migration doesn't affect your\nexisting SLA and business operations.\n\nAssess your deployment and administration process\n-------------------------------------------------\n\nTo ensure that there aren't any unnecessary interruptions to your production\nenvironment, we recommend that you assess the operational and deployment\nprocesses of your database. The assessment should help you to determine how your\ndatabases need to be adapted to facilitate a successful migration.\n\n- Assess how you define and enforce [security policies](https://docs.redis.com/latest/rc/databases/create-database/#security-section) for your database instance to control access to your database.\n- Assess your [monitoring and alerting requirements](https://docs.redis.com/latest/rc/databases/create-database/#alerts-section) by defining notification emails sent to your account and the conditions that trigger them.\n- Collect and visualize your Redis Cloud metrics by using the Redis [Prometheus and Grafana integration](https://docs.redis.com/latest/rc/cloud-integrations/prometheus-integration/).\n\nWhat's next\n-----------\n\n- Read [Google Cloud data migration content](/solutions/database-migration).\n- For more in-depth documentation and best practices, review [RIOT documentation](https://developer.redis.com/riot/).\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture).\n\nContributors\n------------\n\nAuthors:\n\n- [Saurabh Kumar](https://www.linkedin.com/in/saurabh-kumar-48556a19) \\| ISV Partner Engineer\n- [Gilbert Lau](https://www.linkedin.com/in/gilau) \\| Principal Cloud Architect, Redis\n\n\u003cbr /\u003e\n\nOther contributors:\n\n- [Chris Mague](https://www.linkedin.com/in/chris-mague-35b1624) \\| Customer Engineer, Data Management\n- [Gabe Weiss](https://www.linkedin.com/in/weissgabriel) \\| Developer Advocacy Manager\n- [Marco Ferrari](https://www.linkedin.com/in/ferrarimark) \\| Cloud Solutions Architect\n\n\u003cbr /\u003e"]]