Finalize prioritized backlog of application groups
Now that the application and infrastructure is discovered and classified, start thinking about prioritizing them. Other factors start coming into play like e.g. age of hardware and proximity to refresh, systems running at capacity, etc.
Ordering of an application migration is dependent on the prioritization strategy of the organization and the application priority. Now the data gathered from the discovery is crucial because it will decide to migrate based on the complexity. Because lift and shift is the simplest strategy, it will have the highest priority. Regardless, this is where a final list of application and infrastructure s is established and what application groups will move when.
Setting priorities
Evaluate the infrastructure or the group of applications that will move to the cloud. With multiple critical applications, prioritization is done in application groups. Correctly determining the existing business application and infrastructure footprint is essential.
Step 1: Identify the type of application
Now it is essential to recognize the type of application. If the application is business critical, then it should have the lowest priority for cloud migration because of the uncertainty of the new infrastructure.
Check if there are any legal requirements of co-location of applications and data in a particular place. In case the cloud encompasses multiple geographical locations, consider legal stipulations as well as capabilities of the selected cloud platform, before application migration.
Get clarity on questions such as:
What is the level of the application?
- Production
- Non-Production
- Acceptance
- Testing
- Development
What is the data consideration for the application?
- Stateful data
- Stateless data
- Etc.
How was the application developed?
- Third-party purchase
- Written in-house
- Written by partner
- Etc.
Step 2: Consider usage patterns
Usage patterns in terms of predictability, unpredictability and consistency should be considered. This will help identify the amount of hardware volatility needed during application migration to the cloud.
For instance, if the usage pattern is unpredictable with peak loads causing SLA misses, such an application should have a higher priority to be moved to the cloud. This will ensure that the organization would be equipped to handle SLA misses.
Get clarity on questions such as:
What is the application operational standard?
- Defined maintenance windows
- Defined SLA
- Uptime-sensitive
- Latency-sensitive
- Accessed globally or regionally
- Deployed manually or via automation
What is the specific application compliance or regulatory requirement?
- ISO 27000
- PCI/DSS
- HIPAA
- EU Personal Data Protection
- GDPR
What are the business considerations?
- Is the system used year-round or seasonally?
- Is there a line-of-business owner?
- Does the application support a business use case?
- Is the application managed by a central IT team?
- Would a downtime window be acceptable for the application?
Step 3: Determine if the application needs internal or external user support
Applications that have external users will have lower priority of migration to the cloud than those with internal users. External user support implies exposing the private cloud over the demilitarized zone (DMZ) and to the outside world as well. In such a situation, additional security measures are required in the private cloud.
Get clarity on questions such as:
What application dependencies are there?
- How many users depend on it?
- What is the downtime sensitivity?
- Etc.
What are the interdependent applications?
- Oracle
- Citrix
- SAP
- Management server
- Custom or in-house applications
- Etc.
What are the interdependent workflows?
- Messaging
- Monitoring
- Maintenance
- Management
- Etc.
Step 4: Application architecture and design considerations
Validate if the application architecture and design promote parallelism of operations. Make the application compliant to multithreaded execution capabilities, wherein they can be divided into smaller tasks and jobs so it can run independently on their own on definite sets of machines. This will help application migration and efficient utilization of the private cloud.
Distribution of tasks will ensure division of the application across multiple VM’s on the private cloud after application migration. It will help achieve higher scalability and performance and guarantees reliability of applications at the request level.
Get clarity on questions such as:
What kind of documentation is readily available, and is it up-to-date?
- System diagram
- Network diagram
- Data flow diagram
- Build/deploy docs
- Installation documentation
- Standard operation procedure
- Ongoing maintenance docs
- High-level design / Low-level design
- Macro design / Micro design
- Etc.
What are the migration implications?
- Easy to lift-and-shift as-is into the cloud
- Require application refactoring
- Need to modernize before migration
- Need to modernize after migration
- Need to rewrite in the cloud from scratch
Where is the database and storage located?
- Separate servers
- Co-located servers
- Storage block- or file-level
Step 5: Check dependencies
Consider the latency and bandwidth constraints in communicating with components/services that cannot be migrated to the cloud, before any application migration. If the application is dependent on third-party software, there could be issues with licensing, as policies might be different. There may also be compatibility issues that need to be checked before application migration to the cloud.
Get clarity on questions such as:
Which dependencies services to analyze?
- Web services
- Remote Procedure Call system (RPC)
- Backup services
- Unique dependencies
- Manual processes required
- Synchronized downtime/uptime
Defining application groups
When the details are clear of the infrastructure components and applications, the prioritization is completed. The next step is to break the list into manageable pieces, otherwise known as application groups which are smaller, self-contained groups of applications, hardware, software, and service dependencies that can move as a unit. The application groups then must be matched with a proper target, or right-sized to the proper cloud instance size.
Tasks
- Assign point value for each factor based on its importance.
- Tally point values for cloud infrastructure and roll-up to the application or migration group level.
- With the application and migration group list ranked in descending order, review the outcome to ensure they make sense and are feasible.
- Applications at the top of the stack should be investigated with a deeper discovery, target state design, migration planning, and ultimately migration.
- Select one or more applications and the supporting system interdependencies to move as a unit.
- Collect dependency details for the relevant applications that are part of the application group.
- Match the applications processing and memory workload with the properly sized cloud target instance.
- Select application members and dependencies to create the application groups which consist of groups of interrelated and interdependent servers.
- For accuracy use a multitude of methods to produce accurate application dependency mapping (ADM) data.
- Select relevant applications and right-size the aforementioned application workloads.
- Divide the workloads into sub-workloads to fit given size instances.
- Choose the best matching cloud instance sizes for a given workload.
- Initiate a quality assurance process to check data currency, consistency and accuracy.
- Update cloud data repository.
Hints and tips
- Review the available management information reports.
- Talk to consumers of generated reports and assess stakeholder satisfaction.
- Focus on quick wins in early sprints.
- Application cloud eligible is a virtualized x86 compliant, has well-defined boundaries, known cloud licensing model available and known dependencies.
- Application cloud friendly is horizontally scalable, leverage application services, and vendor cloud image available at cloud vendors.
- Application cloud native is having a micro services architecture, “API- first” design, design and built in fault tolerance and is able to bundle the metrics.
- Application not cloud ready is having a hardware appliance, running non-x86 workloads, cloud licensing restrictions and is on-premise dependent.
- Existing applications must be assessed to determine which workloads can benefit most from early migration to the cloud.
- Backlog prioritization contains:
- Cloud infrastructure components like size of systems, file systems, amount of databases, storage volumes, and network setup.
- Usage patterns.
- Internal or external support.
- In-house development or original equipment manufacturer (OEM) software.
- Application complexity of the technology stack, architecture, and dependencies.
- Business criticality with impact, frequency of use, and size of user base.
- Environment priority of development, test, pre-production, or production.
- Transactional load such as resource utilization, scalability and performance.
Activity output
- Finalized priority backlog of application groups
- Sprint backlog
- Updated cloud data repository
