cache-faq.yml

### YamlMime:FAQ
metadata:
  title: Azure Cache for Redis FAQ
  titleSuffix: Azure Cache for Redis
  description: Learn the answers to common questions, patterns, and best practices for Azure Cache for Redis
  author: flang-msft
  ms.author: franlanglois
  ms.service: cache
  ms.topic: faq
  ms.date: 04/12/2022
  
title: Azure Cache for Redis FAQ
summary: |
  Learn the answers to common questions, patterns, and best practices for Azure Cache for Redis.
  
  * [Planning FAQs](cache-planning-faq.yml)
  * [Development FAQs](cache-development-faq.yml)
  * [Management FAQs](cache-management-faq.yml)
  * [Common monitoring and troubleshooting FAQs](cache-monitor-troubleshoot-faq.yml)

sections:
  - name: Deprecated Services
    questions:
      - question: Which Azure Cache for Redis services were deprecated?
        answer: |
          - Managed Cache service -[Managed Cache service](https://azure.microsoft.com/blog/azure-managed-cache-and-in-role-cache-services-to-be-retired-on-11-30-2016/) was retired November 30, 2016.
            
          - In-Role Cache - [In-Role Cache](https://azure.microsoft.com/blog/azure-managed-cache-and-in-role-cache-services-to-be-retired-on-11-30-2016/) was retired November 30, 2016.
                          
  - name: Caches with a dependency on Cloud Services (classic) 
    questions:
      - question: What should I do with any instances of Azure Cache for Redis that depend on Cloud Services (classic)?
        answer: |
          You should migrate all caches with a dependency on [**Cloud Services (classic)**](https://azure.microsoft.com/updates/cloud-services-retirement-announcement/). In August 2021, we announced Cloud Services (classic) will be retired on August 31, 2024. Any instances of Azure Cache for Redis that are dependent on Cloud Services (classic) need to be retired by the same date. 
          
          You should migrate caches with a dependency on Cloud Services (classic) before August 31, 2024.

      - question: How many caches are affected? 
        answer: |
          We’ve made an effort to migrate as many caches as transparently possible. Because of this, few caches and customers are affected.  

      - question: How do I know if a cache is affected? 
        answer: |
          Affected caches fit into one of three groups: 

          - Caches using Classic Virtual Network (VNet) injection

             Any cache injected into a Classic VNet defaults to being built on Cloud Services.

          - Caches in an Azure Resource Manager (ARM) VNet subnet that once contained a Cloud Services-based cache. 
            
             Once a Cloud Services-based cache is contained in a VNet subnet, all other caches in that subnet must also rely on Cloud Services 

          -  Caches using geo-replication that were once replicated with a cache built on Cloud Services. 
          
               This case is rare, but there are a few caches that are use Cloud Services because they were originally geo-replicated with a Cloud Services-based cache.  
        
          Emails will go out to customers identifying the specific subscriptions and cache names affected. If you’d like to confirm whether your cache is affected, send an email to [azurecachemigration@microsoft.com](mailto:azurecachemigration@microsoft.com). 
     
      - question: What is the solution? 
        answer: |
          We have migrated most  caches from being built on Cloud Services (class) to being built on virtual machine scale sets. Migrating to virtual machine scale sets removes the dependency. There are two ways to initiate this process for caches in a VNet: 

          - Migrate to a new cache using Private Links (recommended). 

             Create a new cache that uses Private Link for network isolation rather than VNet injection and [migrate your data to this cache](cache-vnet-migration.md). This option gives you the best and most secure network isolation experience, while also ensuring that all new caches are created using updated infrastructure. 
            
          - Migrate to a new cache in a new Azure Resource Manager VNet subnet.  

             This option will fix the underlying dependency on Cloud Services while maintaining a similar VNet experience. We have migrated most caches from being built on Cloud Services (class) to being built on virtual machine scale sets. To migrate, delete the existing cache and create a new cache in a new Azure Resource Manager VNet subnet. For recommended options for migrating the data in the cache, see [Migrate to Azure Cache for Redis](cache-migration-guide.md).  

      - question: My cache isn't using VNet injection, but I received notice that I need to migrate. What should I do? 
        answer: |
          Check to see if your cache is using geo-replication. If so, you’ll need to migrate your data from your current geo-replicated pair to a fresh geo-replicated pair. 
          
          For example: 

            1. Create a new geo-replicated pair of Premium caches that match the same configuration as your current pair of caches. 
            1. Unlink your original pair of geo-replicated caches and [export an RDB file](cache-how-to-import-export-data.md#export) from the primary cache.  
            1. [Import the RDB](cache-how-to-import-export-data.md#import) file into the primary cache in your new geo-replicated pair.  

          The new pair of geo-replicated  caches won't have the same dependency on Cloud Services.

      - question: What happens if caches aren't upgraded/migrated by August 31, 2024? 
        answer: |
          These caches will be shut down, and you'll lose any data in your caches.  

      - question: What is the timeline for support? 
        answer: |
          Retirement will occur in three phases so that you have the maximum amount of time to migrate: 

            01. _Active Stage_ (now to April 30, 2023) 

            	  Caches have full support, with no change in status from today. This period is given to allow customers time to transition off Cloud Service (classic) with minimal interruption. 
            
            01. _Maintenance Stage_ (May 1, 2023 to December 31, 2023) 
            
              	Caches will receive critical security, stability, and bug fixes, but no new features. 

            01. _Inactive Stage_ (January 1, 2024 to August 31, 2024) 
            	  
                Caches will only receive critical security fixes. All customers with support issues will be requested to migrate to a VMSS-based cache before receiving support. Customers must move off their caches by August 31, 2024.  
            
            :::image type="content" source="media/cache-faq/cache-cloud-service-timeline.png" alt-text="picture of a timeline that shows the timeline for retiring cloud services (classic).":::

      - question: Where can I get more information if I have more questions about this retirement? 
        answer: |
          Post any of your questions to the [Q&A page](https://aka.ms/redisretirementquestions) for Cloud Services (classic) retirement. Also, You can send email to [azurecachemigration@microsoft.com](mailto:azurecachemigration@microsoft.com) for more information.  

  - name: General questions
    questions:
      - question: What if my Azure Cache for Redis question isn't answered here?
        answer: |
          If your question isn't listed here, let us know and we'll help you find an answer.
          
            - To reach a wider audience, you can post a question on the [Microsoft Q&A question page for Azure Cache](/answers/topics/azure-cache-redis.html) and engage with the Azure Cache team and other members of the community.

            - If you want to make a feature request, you can submit your requests and ideas to [Azure Cache for Redis User Voice](https://feedback.azure.com/d365community/forum/a96a82f3-0c25-ec11-b6e6-000d3a4f07b8).
            
            - You can also send your question to us at [azurecache@microsoft.com](mailto:azurecache@microsoft.com).