The first phase of our Azure App Modernization program is a digital estate assessment.
SNP’s Digital Estate Assessment service establishes a roadmap to migrate application workloads to the Azure cloud and achieve business objectives such as agility, scale, cost reduction, and enhanced security.
The Digital Estate Assessment Results In Three Deliverables:
- Application Inventory: Provides insight into the technology that drives the business, an understanding of application usage and topology, and determines the overall complexity and associated risk for each line of business application.
- Application Rationalization: After evaluating workloads, determinations are made about the best ways to migrate or modernize each asset in the cloud, or even not to migrate.
- Architecture Models: A cloud solution architecture recommendation is made and costs are estimated for the applications that are moving to Azure.
Inventory Questionnaire Assessment Automation Tool
Whiteboard Weight Solution Pros And Cons
Cloud Solution Architectures Cost Estimates
Retrospective Plan Next Steps
Title, Purpose, Owner
What is the application called and what function does it carry out? Which department owns the application? Who is the product manager?
How frequently is the application updated? Is the application scheduled for a major upgrade, replacement or retirement?
A list of all the services that support each application. This includes front-end, middle-tier, APIs, databases, Windows services, web services, file storage (public files) and any other components that are used by the application.
The number of components that make up an application. These components could be deployed independently and have dependencies on other applications or be dependencies for other applications. In addition to the number of components, you want to be mindful of the technologies that are used to support these components.
Map each application component to a technology, such as .NET, Angular, Java, SQL, Node, etc. By gathering this information, along with application architecture, you will be able to determine which Azure services can support your applications.
Determine who uses the applications, whether they have internal or external users, hours of operation, how many users does the application have on a daily basis, peak days or times. Does the application have a constant load, or is it more heavily used at the beginning or end of the month? The answers to these questions will help formulate the end-state for a move of the application into Azure, including sizing and scaling strategy.
Determine how the application is currently deployed, including whether the different components reside within the organization’s internal network, or on externally accessible servers. Is there an automated process to package and deploy the application (CI/CD)? Does the team use scripts such as PowerShell to perform deployments? How are database changes handled? Do the servers have any third-party components installed on them to allow the application to function properly?
Does the organization have a development, test, and production environment for the application? This will help you create a strategy for the customer’s subscriptions and resource groups, as well as give you a path towards moving the customer’s dev/test environments to Azure as part of the path towards production.
Operational Support Team and Effort
How much operational support does the application require in terms of backups, server reboots, uptime management? How does the support team work with the application e.g. do they need to log in to servers to perform their support tasks? Understanding these will help you determine the type of metrics that have to be accessible to the support team once the application is in Azure. It will also frame the conversation of VMs or containers vs non-VM setup with PaaS or serverless computing.
Service Level Agreements (SLA)
Are the SLI/SLO/SLAs in place for the applications? Do you have deployment outage windows? Is this a mission-critical application?
Are there any external application dependencies? What is the plan to access those dependencies once the application is moved to Azure?
How is access to the application managed? Is it custom authentication, a well-known authentication provider, AD, etc.?
Mapping From On-Premises Resources to Azure
As you learn about the various applications, are you able to create a logical map from the technologies that support the application to technologies available in Azure? For example, if the application is hosted in IIS, it would map to an Azure App Service. If it uses a SQL Server database, it would be mapped to an Azure SQL Database. This would help you determine if you would need to make code changes and the level of effort needed to change the application and get it ready for Azure.
Innovation Complexity (very important)
Identifying where there are resources that map directly from the on-premises world to PaaS lowers the complexity of your move to Azure. Throughout the inventory phase, the partner should be aware of systems or components that would require code changes to support the move. Once those are found, the partner should assess the level of effort needed to make the required changes and make the component compatible with a PaaS or serverless architecture.
The ability to rapidly provision and migrate to Azure resources allows you to react fast to changes in the marketplace and enables success in a global economy.
As demand for your cloud services grows, Azure can scale to meet traffic demands and contract during off-peak periods.
With Azure you can minimize costs related to IT licensing, hardware and infrastructure maintenance.
Microsoft uses a wide variety of physical, infrastructure, and operational controls to help secure Azure. Enable Security Center to quickly strengthen your security posture and protect against threats.