Imagine you are part of a team.
The task is to migrate the cold datacenter to a Microsoft Azure subscription. You have some information already. It has been determined that 10 total servers will be moved. The servers are all currently shut down (hence, the term ‘cold datacenter’).
The team’s current task is to create an application portfolio. Currently, some team members have a single question:
“What is an application portfolio, and what should it have in it?”
An application portfolio is a dataset of information about all the application ‘in scope’ (in play, so to speak). Essentially, in this case, the applications in scope are the apps that will migrate to Azure.
Now, the bigger question:
What things should an application portfolio contain?
An application portfolio can contain anything relevant for each in-scope application slated for the target migration. However, in my experience, the following information should (at a minimum) be gathered for each application:
- The principal professionals involved with both the migration of applications and this application in particular
They may include Business Analyst, Project Manager, IT Consultants, Infrastructure Management, Database Manager, Network Administrator, Migration Lead and Migration Secondary OnCall, CyberSecurity Engineer, Virtualization Engineer, and more. - A list of the known POTENTIAL risks that can present themselves
These application portfolios will mature and evolve over time, and one of the goals is to resolve all known risks and assumptions. - Specific information about the application
⦁ Is there a support contract for the application, an expiration for the contract, and a due date for it to be renewed (at a discount to the purchase price)?
⦁ How many users are licensed for the application and license key IDs?
⦁ Who is the current SME (Subject Matter Expert) for this application?
⦁ Is the application fully contained in a company-owned datacenter, or is it partly or fully cloud-managed or from the vendor in a SaaS design? SaaS means Software as a Service — basically, you rent the access from the vendor’s datacenter via web access.
⦁ What is the current version of the software available from the vendor and the current version in scope for the migration?
⦁ Is there a list of the names (usually NETBIOS or Fully-Qualified-Domain-Names) of all the servers related to the application, the IP Addresses for all the servers previously named, as well as any/all related database warehouse server names/IP Addresses and any access accounts used by procedures in conjunction with the application?
⦁ Do you have any and all ports used by the application? Any cloud-related URLs and ports?
⦁ Do you know the application vendor’s name, website, and addresses, both physical and email? - The accounts needed to run the application, such as:
All membership groups for users that utilize the application, any shares needed to be set up for the application to work (and what they are currently called and where to locate them), and other applications needed to help this application operate properly. - Links to documentation
These links should support a better understanding of how the application is installed, configured, maintained, and constructed. - The agreed-upon plan of the steps that will take place
This is done to properly migrate the application and related assets. - The timetable of when the migration will start and complete
A Gantt chart is a plus here. - An idea of how the migration will be tested for post-migration success
Devise a plan on what specifics need to be tested before the application goes live and how you’ll go about performing the test. - Contingencies that must be resolved
Specifically, focus on the circumstances you must sort out before the migration can begin, such as upgrading the application to the current state, upgrading the datacenter infrastructure in preparation for migration activities, etc.
Answering as many of the questions above as you can help solidify an application portfolio with the substance to support a successful migration