edits

Author: v-thepet

articles/azure-cache-for-redis/cache-migration-guide.md

@@ -14,23 +14,20 @@ appliesto:
 ---
 # Migrate to or between Azure Cache for Redis instances
 
-This article describes several Azure Cache for Redis migration scenarios.
+This article describes several Azure Cache for Redis migration scenarios. You can migrate Redis caches running in private data centers, on cloud virtual machines (VMs), or in another cloud to Azure Cache for Redis.
 
-- Migrate Redis caches running in private data centers, on cloud virtual machines (VMs), or in another cloud to Azure Cache for Redis.
-- Migrate one Azure Cache for Redis instance to another instance.
-
-If you only need to move an Azure Redis cache from one Azure region to another, see [Move Azure Cache for Redis instances to different regions](cache-moving-resources.md) article.
+You can also migrate one Azure Cache for Redis instance to another instance. If you only need to move an Azure Redis cache from one Azure region to another, see [Move Azure Cache for Redis instances to different regions](cache-moving-resources.md).
 
 Open-source Redis can run in many compute environments, such as private on-premises data centers or cloud-hosted virtual machines (VMs). Other hosting platforms like Amazon Web Services (AWS) host Redis cache services like AWS ElastiCache. You can usually migrate these Redis caches to Azure Cache for Redis with minimal interruption or downtime.
 
 ## Migration options
 
-How you migrate from one cache to another depends on where your cache exists and how your application interacts with it. The following table lists the frequently used migration strategies.
+How you migrate from one cache to another depends on where your cache exists and how your application interacts with it. The following table lists frequently used migration strategies.
 
    | Option       | Advantages | Disadvantages |
    | ------------ | ---------- | ------------- |
    | Create a new cache | Simplest to implement. | Must repopulate data to the new cache, which might not work with some applications. |
-   | Export and import data via read-only database (RDB) file. | Usually compatible with any Redis cache. | Data written to the existing cache after the RDB file is generated could be lost. | 
+   | Export and import data via read-only database (RDB) file. | Compatible with any Redis cache. | Data written to the existing cache after the RDB file is generated could be lost. | 
    | Dual-write data to two caches. | No data loss or downtime, uninterrupted cache operations, and easier testing. | Needs two caches for an extended time period. | 
    | Migrate data programmatically. | Full control over how data is moved. | Requires custom code. | 
 
@@ -46,7 +43,7 @@ General steps to implement this option are:
 
 ### Export data to an RDB file and import it into Azure Cache for Redis
 
-Open-source Redis defines a standard mechanism to take a snapshot of a cache's in-memory dataset and save it to an RDB file that any Redis cache can read. Azure Cache for Redis [Premium tier](cache-overview.md#service-tiers) supports importing data into a cache instance via RDB file. You can use an RDB file to transfer data from an existing cache to Azure Cache for Redis.
+Open-source Redis defines a standard mechanism to take a snapshot of a cache's in-memory dataset and save it to an RDB file that any Redis cache can read. Azure Cache for Redis [Premium tier](cache-overview.md#service-tiers) supports importing data into a cache instance via RDB file. You can use the RDB file to transfer data from an existing cache to Azure Cache for Redis.
 
 > [!IMPORTANT]
 > RDB file format can change between Redis versions and might not maintain backward compatibility. The Redis version of the cache you export should be equal to or lower than the version that Azure Cache for Redis provides.
@@ -56,17 +53,17 @@ General steps to implement this option are:
 1. Save a snapshot of the existing Redis cache. You can [configure Redis to save snapshots](https://redis.io/topics/persistence) periodically, or save manually using the [SAVE](https://redis.io/commands/save) or [BGSAVE](https://redis.io/commands/bgsave) commands. The RDB file is named *dump.rdb* by default and is located at the path specified in the *redis.conf* configuration file.
 1. Create a new Premium-tier Azure Cache for Redis instance that's at least as large as the existing cache.
 1. Copy the RDB file to an Azure storage account in the region where your new cache is located. You can use `AzCopy` for this task.
-1. [Import the RDB file into the new cache](cache-how-to-import-export-data.md). You can also use the [PowerShell Import cmdlet](/powershell/module/az.rediscache/import-azrediscache).
+1. [Import](cache-how-to-import-export-data.md#import) the RDB file into the new cache. You can also use the PowerShell [Import-AzRedisCache](/powershell/module/az.rediscache/import-azrediscache) cmdlet.
 1. Update your application to use the new cache instance.
 
 > [!NOTE]
-> To migrate data from another Azure Redis instance, first [export the RDB file](cache-how-to-import-export-data.md) from that instance, or use the [PowerShell Export cmdlet](/powershell/module/az.rediscache/export-azrediscache).
+> To migrate data from another Azure Redis instance, first [export](cache-how-to-import-export-data.md#export) the RDB file from that instance, or use the PowerShell [Export](/powershell/module/az.rediscache/export-azrediscache) cmdlet.
 
 ### Write to two Redis caches during migration
 
 Rather than moving data between caches, you can temporarily set your application to write data to both an existing cache and a new one. The application reads data from the existing cache initially. When the new cache has enough data, you switch the application to that cache and retire the old one.
 
-For example, suppose you use Redis as a session store and the application sessions expire after seven days. After writing to both caches for seven days, you know the new cache contains all nonexpired session information and you can safely rely on it from that point onward.
+For example, suppose you use Redis as a session store and the application sessions expire after seven days. After writing to both caches for seven days, you know the new cache contains all nonexpired session information and you can safely rely on it from that point on.
 
 General steps to implement this option are:
 
@@ -78,7 +75,7 @@ General steps to implement this option are:
 
 ### Migrate programmatically
 
-You can create a custom migration process by programmatically reading data from an existing cache and writing it into Azure Cache for Redis. For example, you can use this open-source [redis-copy](https://github.com/deepakverma/redis-copy) tool to copy data from one Azure Redis instance to another.
+You can create a custom migration by programmatically reading data from an existing cache and writing it into Azure Cache for Redis. For example, you can use the open-source [redis-copy](https://github.com/deepakverma/redis-copy) tool to copy data from one Azure Redis instance to another.
 
 The source code can be a useful guide for writing your own migration tool. A [compiled version](https://github.com/deepakverma/redis-copy/releases/download/alpha/Release.zip) is also available.
 
@@ -89,7 +86,7 @@ General steps to implement this option are:
 
 1. Create an Azure virtual machine (VM) in the same region as the existing cache. If your dataset is large, choose a powerful VM to reduce copying time.
 1. Create a new Azure Cache for Redis instance and make sure that it's empty. The `redis-copy` tool doesn't overwrite any existing keys in the target cache.
-4. Use an application such as `redis-copy` to automate copying the data from the source cache to the target cache. The copy process could take awhile depending on the size of your dataset.
+4. Use an application such as `redis-copy` to automate copying the data from the source cache to the target cache. The copy process could take a while depending on the size of your dataset.
 
 ## Related content
 

articles/azure-cache-for-redis/cache-reserved-pricing.md

@@ -17,7 +17,7 @@ appliesto:
 
 Reservations in Azure Cache for Redis can help you save money compared to pay-as-you-go prices by prepaying for compute resources. With reservations, you make an upfront commitment on a cache for one or three years to get a significant discount on the compute costs.
 
-You purchase Azure Cache for Redis reservations for a specific Azure region, Azure Cache for Redis tier, and term. You don't need to assign the reservation to specific cache instances. Existing and new caches automatically get the benefit of reserved pricing, up to the reserved cache size.
+You purchase an Azure Cache for Redis reservation for a specific Azure region, Azure Redis tier, term, and node quantity. You don't need to assign the reservation to specific cache instances. Existing and new caches automatically get the benefit of reserved pricing, up to the total reservation size.
 
 When you purchase a reservation, you prepay for compute costs for one or three years. As soon as you buy the reservation, the compute charges that match the reservation attributes no longer use the pay-as-you go rates.
 
@@ -43,13 +43,13 @@ Reservations are sold in increments of nodes. Premium-tier and Enterprise-tier A
 
 The Enterprise Flash tier contains three nodes by default, so for Enterprise Flash tiers you need to buy three reservation units.
 
-To calculate number of nodes, see **View Cost Calculation** in the [Pricing calculator](https://azure.microsoft.com/pricing/calculator/).
+To calculate number of nodes, see the [Pricing calculator](https://azure.microsoft.com/pricing/calculator/).
 
 ### Reservation size determination
 
 Base your reservation size on the total amount of memory size that the existing or soon-to-be-deployed caches use within the specific region and tier.
 
-For example, suppose you run two caches, one at 13 GB and the other at 26 GB. You need both caches for at least one year. You plan to scale the existing 13 GB cache to 26 GB for a month to meet your seasonal demand, and then scale back.
+For example, suppose you run two caches, one at 13 GB and the other at 26 GB. You need both caches for at least one year. You plan to scale the existing 13-GB cache to 26 GB for a month to meet your seasonal demand, and then scale back.
 
 In this case, you could purchase either one P2-cache and one P3-cache or three P2-caches on a one-year reservation to maximize savings. You receive a discount on the total amount of cache memory you reserve, independent of how that memory is allocated across your caches.
 
@@ -70,10 +70,12 @@ To buy reservations using the Azure portal:
 1. In the **Select the product you want to purchase** pane, select the **Scope** and **Subscription** you want to use for the reservation.
 1. Select the values you want from the dropdown lists for **Region**, **Term**, and **Billing frequency**.
 
+   :::image type="content" source="media/cache-reserved-pricing/cache-reserved-price.png" alt-text="Screenshot showing an overview of reserved pricing.":::
+
    The following table describes the form fields in detail.
 
    | Field | Description |
-   | :------------ | :------- |
+   | ------------ | ------- |
    | Subscription   | The subscription used to pay for the reservation. The subscription type must be EA, offer numbers MS-AZR-0017P or MS-AZR-0148P, or an individual agreement with pay-as-you-go pricing, offer numbers MS-AZR-0003P or MS-AZR-0023P. For an EA subscription, the charges are deducted from the enrollment's Azure Prepayment balance or charged as overage. For pay-as-you-go, the charges are billed to the subscription's credit card or invoice.|
    | Scope | The reservation's scope. <br>**Shared** applies the reservation discount to cache instances in any subscriptions in your billing context. For EA, the shared scope is the enrollment and includes all subscriptions within the enrollment. For pay-as-you-go, the shared scope is all pay-as-you-go subscriptions created by the account administrator. <br>**Single subscription** applies the reservation discount to cache instances in this subscription. <br>**Single resource group** applies the reservation discount to instances in the selected resource group within the subscription. <br>**Management group** applies the reservation discount to matching resources in subscriptions that are a part of both the management group and billing scope.|
    | Region | The Azure region for the reservation.|
@@ -83,16 +85,15 @@ To buy reservations using the Azure portal:
 
    Existing or new caches that match the attributes you select get the reservation discount. The actual number of instances that get the discount depends on the scope and quantity you select.
 
-   :::image type="content" source="media/cache-reserved-pricing/cache-reserved-price.png" alt-text="Screenshot showing an overview of reserved pricing.":::
-
 1. Select the reservation you want, and note the **Monthly price per node** and estimated savings calculated at lower right.
 1. Select **Add to cart** and then select **View cart** to close the product list pane.
 1. On the **Purchase reservations** page, review the reservation details.
-1. **Auto-renew** automatically renews your reservation at the end of the term and is set to **On** by default. You can set it to **Off** now or any time before the end of the term.
+1. **Auto-renew** is **On** by default to automatically renew your reservation at the end of the term. You can set it to **Off** now or any time before the end of the term.
 1. Select **Next: Review + buy**.
 1. Review the details, **Additional notes**, **Today's charge**, and **Total cost**, and then select **Buy now**.
 
 - You can update the scope of the reservation through the Azure portal, PowerShell, Azure CLI, or the API.
+
 - You can cancel, exchange, or refund reservations with certain limitations. For more information, see [Self-service exchanges and refunds for Azure Reservations](/azure/cost-management-billing/reservations/exchange-and-refund-azure-reservations).
 
 ## Related content

articles/azure-cache-for-redis/cache-retired-features.md

@@ -15,16 +15,21 @@ appliesto:
 
 # Redis version 4 retirement in Azure Cache for Redis
 
-On June 30, 2023, Redis version 4 was retired for Azure Cache for Redis instances. All new Azure Redis instances are version 6. To check the Redis version of your cache instance, select **Properties** from the left navigation menu of your cache page in the Azure portal.
+On June 30, 2023, Redis version 4 was retired for Azure Cache for Redis instances. All new Azure Redis instances are version 6.
 
-All existing Azure Redis instances were upgraded automatically to version 6 in 2023. Caches that had a maintenance window scheduled were upgraded during the maintenance window. Redis version 6 is compatible with version 4 and applications continued to function seamlessly after the version upgrade.
+
+All existing Azure Redis instances were upgraded automatically to version 6. Redis version 6 is compatible with version 4 and applications continued to function seamlessly after the version upgrade.
 
 During the upgrade process, the replica node of the cache was first upgraded to run Redis version 6. The upgrade replica node then took over as the primary cache node while the former primary node rebooted to take on the role of replica. This process was exactly like the patching process described in [How does patching occur?](cache-failover.md#how-does-patching-occur)
 
-Standard and Premium caches were fully functional and available during the upgrade process. Applications saw a connection blip for a few seconds. Basic caches were unavailable during the upgrade and all data was lost.
+- Caches that had a maintenance window scheduled were upgraded during the maintenance window.
+
+- Standard and Premium caches were fully functional and available during the upgrade process. Applications saw a connection blip for a few seconds. Basic caches were unavailable during the upgrade and all data was lost.
 
-Cache instances that had geo-replication enabled had to unlink the caches before upgrade, upgrade both caches, and relink them after the upgrade.
+- Cache instances that had geo-replication enabled had to unlink the caches before upgrade, upgrade both caches, and relink them after the upgrade.
 
-Cache instances that were affected by Cloud Service retirement couldn't upgrade to Redis 6 until after they migrated to a cache built on Virtual Machine Scale Set. Otherwise the automatic migration required around 30 minutes of downtime and full data loss on the cache. For more information, see [Caches with a dependency on Cloud Services (classic)](../redis/faq.yml).
+- Cache instances that were affected by Cloud Service retirement couldn't upgrade to Redis 6 until after they migrated to a cache built on Virtual Machine Scale Set. Otherwise the automatic migration required around 30 minutes of downtime and full data loss on the cache.
 
 For more information about upgrading Redis versions in Azure Cache for Redis, see [How to upgrade the version of your Redis instance](cache-how-to-upgrade.md). The upgrade process can be triggered through REST API, Azure CLI, or PowerShell command. Also see [Best practices for connection resilience](cache-best-practices-connection.md).
+
+To check the Redis version of your cache instance, select **Properties** from the left navigation menu of your cache page in the Azure portal.