application portfolio

What Information Should an Application Portfolio Contain?

Marty NickisonLeave a comment

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:

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. Links to documentation
    These links should support a better understanding of how the application is installed, configured, maintained, and constructed.
  6. The agreed-upon plan of the steps that will take place
    This is done to properly migrate the application and related assets.
  7. The timetable of when the migration will start and complete
    A Gantt chart is a plus here.
  8. 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.
  9. 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

What Is Meant by ‘New Builds’ When Discussing Cloud Migration?

Marty NickisonLeave a comment

Let’s assume we plan to move two applications from the local datacenter into a Microsoft Azure subscription. We will call the applications “LiftAndShift” and “NewBuild.” For the purpose of simplicity, let’s assume each application is hosted on one server: “LiftAndShift1” and “NewBuild1”.

First, we create a space for these servers and applications to live on.

Since they share data and talk to each other via shared folders on each server, we decided to create a single tenet that will ‘house’ both servers above.

Next, we meet with the application portfolio team, stakeholders, and power users.

This meeting happens so that we can agree on a sequence of events for moving these two applications. This agreement is CRITICAL as both servers need each other, and we must minimize the risk of downtime while this migration takes place. Furthermore, we must test as many things as we can as we go through this process.

We decide to use the Azure Migrate Tool to move “LiftAndShift1” first. This server is currently a virtual machine hosted on a VMware EXSi cluster of hosts running ESXi 6.5 Update 3 (build 13932383). We then download the Azure Migrate Tool from the Microsoft Azure tenet we created.

Next, it is installed as an appliance (*.ova file) into vSphere. Finally, it is configured with an Admin-level account for both SQL on-prem and the Windows Active Directory (SPECIFICALLY USED JUST FOR THIS PURPOSE — AS DIRECTED BY LEADERSHIP, NAMELY THE CISO).

A cutover weekend plan is established.

The prior weekend, we ran an assessment for “LiftAndShift1” using that functionality in the Azure Migrate section of the Microsoft Azure portal. Since this application is very ‘lean’ (small), the VMware virtual server on which the application ‘sits’ is also quite small.

The Azure Migrate Tool successfully completes the initial assessment and recommends two drives and a B2s target to migrate this virtual server directly into the Azure Tenet.

The cutover of “LiftAndShift1” is a success, and the afterward testing completes with no major concerns.

In compliance with the plan created above, the “NewBuild1” server will not be migrated. Instead, we will move the server via a ‘new build’ process.

Now we commence with a ‘new build’ migration.

What does this mean? Simply stated, a ‘new build’ migration is when you first create a new server in the cloud with more than enough resources to run the application, data, etc.

Next, you install the most current version of the software the server will run on. There is one pre-requisite, though; you need to engage the vendor to assure you have access to the most current software. You’ll also need to get the support contracts and proper license structures for it.

Finally, you set up another cutover weekend where all the data is copied to the new location, and the new server is configured to work with the new data copy. It then needs to be tested by the power users to assure functionality.

So, when the expression ‘new build’ is used in the context of cloud migration (e.g., migrating a server to Microsoft Azure), it refers to creating a new server so house data will be updated and then copied to that new server. The base server (operating system, etc.) will NOT BE MIGRATED using tools like Azure Migrate Tool and the HCX appliances.