Application to Cloud, Self-Assessment Checklist
Assessing or evaluating your existing applications and moving them to the Cloud, is often the most time consuming part of the cloud transition. Implementing a private cloud, or procuring some public cloud services, is often completed within one year; however, assessing and then migrating a dozen and up to 100 applications could take a couple of years. The time it takes to perform assessments depends on (at least) three factors:
- Internal technical capabilities versus hiring external application transformation consultants
- Quantity of legacy applications and how many are complex or custom built
- Available budget as it relates to how many parallel assessment teams and work streams
Using the guidelines and checklists that follow, you should be able to self-assess many of your basic applications, saving you precious time and money and defer hiring external application transformation-to-cloud experts for only the most complex requirements.
If your organization is very large or has hundreds or thousands of applications, seriously consider using these application transformation experts who specialize in app modernization factories that have numerous experienced teams and proven processes for analyzing and migrating large quantities of applications in parallel work streams.
Figure: Application assessment steps
Even if your organization decides to hire experts for more formal application assessments or actual application migrations, the information gathered by completing this self-assessment can be a significant head start.
Initial application assessment checklist
DATA GATHERING
- List and prioritize applications
- Create a list of all COTS [customized off the shelf] and custom-built applications along with the primary use case or business function performed by each
- Specifically note the name of each application, the manufacturer/software vendor, and version of the application, if known
- Note any significant customizations to COTS applications that have been made and any updates that might have been intentionally skipped or avoided due to potential conflicts with these customizations
- Prioritize these applications lists based on criticality to the business, how broadly the application is utilized across the business (i.e., how many users), and if this is a customer-facing or internally focused application
- Flag applications that are seldom used, are candidates for retirement, have been considered for replacement already, and any workloads for which the cloud has been considered already
Data classification
Consider each application and particularly its data; rank the impact to the organization if the data is corrupted, or completely lost (requiring a data restore. Classify applications to determine which model they should follow (i.e., the highest-risk applications/data are likely candidates for a private cloud, whereas less-risky applications/ data are candidates for public or community cloud models)
Categories:
Lower Impact Level
The unauthorized disclosure of information might have a limited adverse effect on the organization.
Moderate Impact Level
The unauthorized disclosure of information might have a serious adverse effect on the organization.
High Impact Level
The unauthorized disclosure of information might have a severe or catastrophic adverse effect on the organization.
Also note any compliance or similar requirements such as industry or government regulations that might impact the application design, security controls, where data is stored or who has access to and administration of the application and data.
Architecture
Understand the following and list each application against these targets.
- Application architecture
- Is the application currently hosted on a single server, spanned across multiple services? Is there a backend database? Can frontend services (web, client-facing application interfaces) be separated into their own network segment from the rest of application, database, middleware?
- Does the current application use a multitiered architecture such as separate database, middleware, and frontend processing services?
- Can the application and middleware be separated into its own network segment, forming two or three tiers of networks?
- Can or should the application share a common database, middleware, or other application or PaaS-type services? [Shared services could increase security but reduce licensing costs and easier to manage in an automated environment].
- What application platform or programming language was used as the basis for the application (if known)?
Application modernization and migration
For every application, consider the cost, effort, and risks to redesigning/recoding and if the application is worth the effort, cost, and risk; consider moving commodity applications, such as email, to hosted or even public cloud services. This is critical. Many ERP, client-server apps are not Cloud friendly and do not possess Web Services code models which are mandatory for a real Cloud deployment.
- Which applications could be ported “as is” to the cloud using scaled-up (more computer power) cloud servers? Which applications could be ported to the cloud and use hypervisor- level scale out (such as additional frontend servers) without the application having to be recoded?
- Evaluate which applications would benefit from application redesign to take advantage of automation, elasticity, on-demand pay-as-you-go cloud services
- Application management
- Always consider how consumers will order applications, how automation will provision them, and how other automated processes will upgrade and monitor them
- What application settings, customizations, and self-service controls should be available to administrators and users?
- Will there be billing or financial chargeback of application, data, transactions or data fees to the consumers or other departments? Consider how the cloud management platform will handle this.
- What application statistics and reports will need to be presented in the cloud management portal to the customer/ consumers?
- What user roles and groups need to be created/managed?
- How will user authentication and identity for logon to each application be managed and federated through cloud management or other systems?
Operations and governance
Evaluate who is currently, and who should in the future, be performing all application upgrades, data maintenance, and monitoring. Are there existing challenges that could be addressed as part of application transformation (change in personnel responsibilities, governance, etc.)?
- Consider grouping similar application profiles from an operations standpoint into the same cloud model (i.e., private cloud with operations/management by internal employees) versus applications that are commodities (meaning, they could be operated by anyone internal or outsourced) versus mission critical (meaning, they should only be run/operated by specific persons or department).
- Mission criticality- Assess how critical the application and particularly the data is to your customers and/or the mission of the organization.
Preliminary decisions
Form an initial decision as to which applications are good candidates for a cloud migration, which apps should remain hosted within internal datacenters, and which workloads should not be migrated or dealt with immediately:
- Consider which applications and workloads are best fits for hosting within an internal private cloud and which might be appropriate for a public cloud
- This preliminary decision should be based on the assessment steps described earlier compared to the effort (cost, time, ROI) that the migration will require and ultimately the priority to the corporation
Consider hiring external application transformation-to-cloud consulting services to handle the most complex or mission- critical workloads. Have them perform detailed assessments and systems redesigns, select cloud providers/models, develop a cloud migration plan, and conduct a pilot.
