# Planning the migration
Planning your migration process is key to ensuring a smooth and successful migration. The following sections outline how to plan your migration, as well as key considerations for it.
**Topics**
+ [
# Deciding what to migrate
](migration-decision-process.md)
+ [
# Descaling your configurations
](descale-configurations.md)
+ [
# Choosing the instance type
](instance-choice.md)
+ [
# Key decision points
](key-decision-points.md)
+ [
# High-level migration overview
](high-level-migration-overview.md)
# Deciding what to migrate
When you migrate, you have to decide which workloads are essential; which workloads are “nice to have” but not essential; and which workloads are not necessary and can be [retired once the migration is complete.](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html)
A significant part of your decision-making process will involve individual requirements that you have for automation, API, tooling, and other processes. You will also need to consider your organization’s functional and performance requirements.
For example, you might have used shared hardware platforms in an existing data center with user partitions. However, your migration might require that services run on systems that are not as widely shared due to performance limitations of moving from hardware-accelerated solutions. For instance, Secure Sockets Layer (SSL) transactions per second (TPS) could require that a certain service does not run on a shared system.
After you identify and document which applications will migrate and their requirements, you need to prepare your source systems by using the following best practices.
+ Run the same version of F5 TMOS that you will run in the AWS Cloud. [Version 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) or later is recommended, but [version 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) or later can also be used. Although you can migrate version [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html), you might encounter security, automation, and maintainability issues.
+ Have valid backups of all configurations from each device. Since the Univention Corporate Server (UCS) backup contains attributes and objects that are specific to the data center (such as IP addresses, nodes, or pool members), F5 recommends that you create a shell command file (SCF) to edit and merge the configurations.
+ Have backups of all relevant security certificates, and consider changing from RSA to ECC encryption for better performance.
+ Have detailed performance metrics at the virtual server level for scaling and capacity planning.
+ Have an [F5 Global Server Load Balancing (GSLB)](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) solution for the cutover from the data center to the AWS Cloud.
+ Understand the impact of migrating from a hardware appliance model to a software and virtualized model in terms of performance, scalability, and high availability.
+ Have defined requirements of what will be migrated to the AWS Cloud, and be aware of the following considerations.
+ Know that any migration to the AWS Cloud requires decisions about whether entire or partial configurations will be migrated. Typically, one partial move at a time is more efficient.
+ Understand which routes and IP addresses will change.
+ Identify which SNAT pools should be replaced with F5 SNAT Automap.
You should also consider consulting [AWS Partners](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks) or the F5 Professional Services team. This will help ensure a high probability of a successful migration.
# Descaling your configurations
“Descale” means moving an F5 BIG-IP configuration to a lower or more cost-efficient configuration, based on the features or metrics required after your initial discovery findings. You must carefully evaluate all these options because they will impact the architecture and the number of instances required.
The following diagram helps you assess if descaling is appropriate for your needs and requirements.
![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png)
The migration will also create new considerations in the following areas.
+ **Network topology** – AWS does not currently support `802.1q `tagged VLANs, so the number of instance interfaces (minus one for management) present a limit to the number of networks that an instance can support. If you require a specific topology, you need to evaluate it compared to the different instances that F5 supports in the AWS Cloud.
+ **SSL performance** – F5 appliances and chassis have an SSL performance that exceeds what can be accomplished on `x86`. You must evaluate the aggregate and per-virtual server SSL requirements.
+ **Network performance** – You must evaluate the aggregate, outbound, and internal network characteristics. AWS instance types have different network characteristics (low, medium, high, up to X, or dedicated) that must be considered. There are also limits to how much traffic a single instance can send outbound or across a direct connection.
+ **VIP density** – If you have a larger number of virtual IP addresses (VIPs), you must consider the instance limit to the number of VIPs that can be mapped to the network interfaces.
+ **Concurrent connection** – There are flow limits to the maximum number of connections that the instances can support.
+ **Session state** – Different applications use different types of persistence. Stateful and stateless applications will change the methods used to shared state, and this can impact scale for in/out operations.
# Choosing the instance type
F5 supports multiple instance types and choosing which one to use can be a complex decision. For most migrations, `c5n.2xl` and `c5n.4xl` will be the most common instance choices because they offer a mix of network performance, CPU density, interface density, and the number of IPs that can be supported on the instance. The following diagram provides examples of which instances to choose, based on the F5 products you are using.
![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png)
# Key decision points
There are many aspects of migration that need to be considered, but before beginning your F5 BIG-IP workload migration, ask yourself the following questions to clarify the migration process.
**Who are the users of your applications? **
Assess if these are internal (not traversing an Elastic IP address) users or external (traversing an Elastic IP address) users. If the users are internal, evaluate whether the application can use DNS to accommodate the failure of an Availability Zone or active deployment. You should also verify if you need to use an alternate design pattern that allows a subnet to span multiple Availability Zones.
**What parts of your applications will migrate to the AWS Cloud? **
Assess whether the entire application is moving or only the presentation tier. You should also consider additional dependencies around security and DNS namespace. Your evaluation needs to determine what would be required from the network topology. Additionally, determine what is required from a service-level agreement (SLA) should an event happen at the Availability Zone, VPC, or AWS Region level.
**Why is the application migrating? **
You might be migrating your application because you are closing data centers or because you want more elasticity. Assess whether the application is migrating to have a per-application architecture, compared to the shared monolithic patterns common in many data centers. It's also worth considering what modernization efforts should be taking place along with the migration.
**Where is the application migrating to? **
Assess if the application needs to move to a single VPC with one Availability Zone or two Availability Zones. Determine the peer or transit VPC topology, along with the need for multi-Region deployments. These will impact the migration pattern design.
# High-level migration overview
Before you begin the migration, it helps to lay out the entire process from a high level. The following is an example of the steps you might take to migrate an F5 BIG-IP workload to the AWS Cloud. More detailed steps and processes for an F5 BIG-IP migration can be found in the pattern [Migrate an F5 BIG-IP workload to F5 BIG-IP VE on the AWS Cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.html?did=pg_card&trk=pg_card).
1. Deploy the required number of VPCs based on your individual requirements. This can be manual or automated through a tool such as [AWS Landing Zone](https://aws.amazon.com//solutions/implementations/aws-landing-zone/).
1. Evaluate current F5 licenses, utilizations, and configurations.
1. Evaluate public and internal applications.
1. Evaluate current F5 configurations.
1. Evaluate size and IP address requirements, and choose the required number and type of F5 and AWS instances.
1. Identify which migration strategy to deploy. For example, lift and shift; lift, shift and modernize; or hybrid.
1. Evaluate and identify the DNS design.
1. Evaluate how traffic will be directed to the application if it exists both on premises and in the AWS Cloud.
1. Perform initial deployments of F5 instances by using AWS CloudFormation templates.
1. Modify deployments to meet topology requirements with additional elastic network interfaces and route tables.
1. Align Elastic IP addresses to self IPs or management IPs, and plan out Elastic IP to virtual IP (VIP) mapping.
1. Create secondary addresses on elastic network interfaces for VIPs.
1. Apply secondary addresses in the AWS Cloud.
1. Map Elastic IP addresses to secondary address for VIPs.
1. Pull configurations and compile a list of objects to move.
1. Deploy the configurations to F5 BIG-IP.
1. Map the secondary addresses to VIPs.
1. Test traffic.
1. Test failover.
1. If you are building a hybrid, make sure you incorporate the system into F5 DNS.
**Important**
Access to the AWS API endpoints is required. NAT or Elastic IP addresses are also required for high availability within or between Availability Zones.
The following diagram shows the high-level process flow for an F5 BIG-IP migration.
![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png)