Why application prioritization is the foundation of a successful migration The temptation to migrate in parallel, or to start with the most complex application, is strong, but doing the opposite is what minimizes risk and accelerates the project. Poor prioritization creates cascading blockers (you cannot migrate application B until A is stabilized on AWS), wastes time on unidentified prerequisites, and exposes your critical applications to unknowns documented far too late. Good prioritization, on the other hand, unlocks successive low-risk waves and builds your teams' confidence at every step. Among the scale-ups and mid-market companies that have entrusted this work to Stralya, this ranking phase often represents the difference between a rollout that drags on for six months (with unforeseen crises) and one that hits its quarterly milestones. The point is not to predict the future with certainty, but to identify now the three or four criteria that will truly matter: the business impact if the app goes down, the complexity of the migration, and the dependencies that will block you if you get the order wrong. Starting here avoids false starts and sets the rest of the project on a solid foundation. ## The three essential criteria for ranking your applications To build a prioritization matrix that your teams will understand and accept, you need to assess each application along three dimensions that constantly interact. The first criterion is business impact. You need to answer honestly: how much revenue or how many critical processes depend on this application? A back-office application used twice a month by three people does not carry the same weight as an internal service that handles orders in real time. This impact is measured through three interlocking elements: the direct users affected (how many and how often), the downstream services that depend on it (that is, if it goes down, what else stops in a cascade), and the business cost of a one-hour outage (you can sometimes find it in an existing risk analysis, otherwise ask the business unit that owns it). The applications deemed "critical" (high impact) are generally only 10 to 20 percent of your IT portfolio, but they concentrate 80 percent of your migration risk. The second criterion is technical complexity. Some applications are easy to migrate (a stateless application, with no complex database, deployed on a few identical servers), while others are nightmares of interdependencies, custom configurations, obsolete libraries, or massive datasets. For each application, ask yourself: what types of infrastructure does it use (servers, databases, file systems, external services)? Are these infrastructures standardized or heavily customized? How much data must migrate, and how often does it change? Do you have complete documentation, or will you have to reverse-engineer along the way? The more complex an application is, the later it should be attempted in the project, once your teams already have AWS experience and you have refined your processes. The third criterion is the dependencies between applications. If application B cannot function unless application A is already operational (or at least reachable from the cloud), then A must be migrated before B. You will often discover dependencies that no one had explicitly documented: app B calls an API in app A every ten minutes, or app C needs app A to be in place to pull synchronization data every night. These dependencies become the sequencing constraints for your migration waves. Ignoring this dimension guarantees that your second wave will stay blocked on an unmigrated dependency, which itself has unmet prerequisites. ## Building the prioritization matrix in four practical steps Building this matrix does not require months of analysis. Here is how to do it in a few weeks, with your own teams and without an expensive consultant. Step 1: draw up a complete inventory of your applications. List every system running on your current infrastructure (on-premises or legacy cloud), clearly separating business applications, internal tools (GitLab, Jira, data databases), middleware (queues, authentication services), and outsourced services that will not migrate. You should end up with 30 to 150 items depending on your size. For each one, note: the business or technical owner, the current environment (servers, technology, version), and the lifecycle stage (in production for how long, planned end-of-life when). This inventory is your source of truth for the entire migration. Step 2: assess business impact. Organize a session with the business owners of each application (or their representatives). Ask three simple questions for each one: (1) How many people use it and how often? (2) If it goes down, how long until the business suffers serious harm (an hour, a day, a week)? (3) Estimate the business cost of a one-hour outage (lost revenue, angry customers, compliance at risk, and so on). Based on these answers, place each application into an impact category: critical (must always be available), high (a one-hour outage has serious consequences), medium (a one-day outage is acceptable), or low (can be down for a few days). This categorization usually takes two or three days for the whole portfolio. Step 3: assess technical complexity. Work with your infrastructure team and your architects. For each application, document: the type of infrastructure (number of servers, database, storage, specialized tools), data size (a few GB or petabytes), technical dependencies (libraries, OS, other internal systems), and the state of the documentation (do you have a complete spec, or will you be figuring it out as you go). Based on this technical audit, classify each application as low, medium, or high complexity. A standard Linux application with a PostgreSQL database is low complexity. A mainframe application with 50 GB of data and a proprietary configuration is high complexity. Count on three to five days for this exercise. Step 4: identify the critical dependencies. Run a short architecture review: for each application, ask "which other systems must be in place or reachable for this one to function?" You will find some of the answers by examining the logs (who calls whom), and others by asking the development teams directly. Note these dependencies in a simple graph (app A depends on apps B and C, app B depends on app D, and so on). This review usually takes a week, because it often reveals unexpected dependencies that need to be validated. Once these four steps are complete, you have all the ingredients to fill in a simple calculation matrix (a table in a spreadsheet or a collaborative tool): rows for all your applications, columns for the three criteria and the dependencies, and you can finally sequence your waves. ## The recommended migration order: logical and learning waves With your three criteria in hand, here is the logic Stralya recommends for ordering your migrations, tested across dozens of projects. Wave 1 (Validation and learning): Start with one or two applications of low criticality and low complexity. These applications serve as a full-scale test: you will discover how your AWS deployment works, which tools and scripts you actually need, what the real cutover and stabilization time is, and you will train your teams on the pitfalls. These applications have little business impact if something goes wrong, so the learning costs you nothing. They should also be relatively independent (few or no upstream dependencies). This wave often lasts one to three months. Many teams that skipped this wave regretted it later, when they discovered false assumptions about AWS at scale. Wave 2 (Progressive complexity): Next, migrate applications of low to medium criticality but of increasing complexity. This is no longer pure learning, but you still benefit from the error tolerance that low business impact gives you. You can afford rollbacks, in-place fixes, and debugging in production. You refine your runbooks and scripts. This is also where you start migrating applications with simple dependencies (that is, whose dependencies were already migrated in wave 1). This wave usually lasts two to four months. Wave 3 (Critical applications): Only when you are confident in your process and have stabilized AWS should you migrate the high-criticality applications. By this stage, your team has seen the pitfalls, the subtle dependencies have been identified, and your AWS infrastructure is already well understood. The risk is mitigated by the accumulated learning. Because these applications are critical, you put in place more monitoring, more rollback plans, and more load testing. A critical application cannot go down during learning, but it can be migrated with confidence after you have already migrated the non-critical ones. This wave lasts two to four months. Wave 4 (Tail and exotic): The last applications to migrate are those with high complexity and medium or low business impact, or those with many upstream dependencies. You hold them until the end because they are either technically subtle (you have had time to assemble the expertise) or dependent on too many other systems (which are finally in place). This wave can last one to three months and is often less stressful, since 80 percent of your infrastructure is already stable. Beware of a common temptation: attempting all the waves in parallel to "go faster." This creates a chaos of poorly resolved dependencies, zero learning, and overloaded teams that make mistakes. A disciplined sequence of four or five waves actually takes less time (and exposes less risk) than an attempt to do everything at once. ## Common pitfalls and how to avoid them Three mistakes recur regularly in poorly designed prioritizations, and they can be costly. First pitfall: ignoring hidden dependencies. A team thinks it can migrate application A in wave 2, but discovers too late that application A calls an internal API of an application D that was not documented, and that D was supposed to migrate in wave 4. Suddenly, the team cannot finish wave 2. To avoid this, force yourself to validate discovered dependencies with the teams that know them, and add a layer of technical verification (inspect production logs, trace network calls, audit configuration files). A dependency found and reclassified in three days is worth more than a dependency discovered under duress during cutover. Second pitfall: overestimating an application's business impact because it is old or seems important. A legacy "master data" database may seem critical, but in reality it is only queried once a week for reports. You will spend three months migrating it because you thought it was critical, when a proper review would have shown it could wait. To avoid this, insist that the business impact assessment be done by the business owners themselves, not by an IT department that guesses. A shared spreadsheet where each business unit fills in its three impact questions creates accountability and reveals differing opinions (which you can then resolve in a workshop). Third pitfall: changing the prioritization during the project for short-term reasons. "App X did not seem urgent, but the director changed his mind, so we are doing it now." This introduces dependency chaos (you had planned that app X depended on app Y, you change the order, and now Y will not be ready for two months). Establish a firm prioritization at the start, document the assumptions behind each choice, and reserve reclassifications for a formal review every three months, based on facts ("the business impact was misjudged") rather than on the mood of the moment. A stable, explicit prioritization earns team buy-in far better than one that changes every week. ## Validate and document your prioritization before you begin Once you have built your prioritization matrix and defined your four waves, do not launch your migrations immediately. You need three short validation steps. First, present the prioritization to a governance committee (CIO, key business owners, CTO). This committee does not review every line, but validates that the broad principles are respected: the critical applications are indeed in wave 3, not wave 1, the most sensitive dependencies are indeed resolved before their consumer, and the lessons from wave 1 will indeed serve wave 2. This review surfaces unresolved disagreements (a business owner may contest that his application is classified medium when he considers it critical): far better to resolve them in a one-hour meeting than to discover the problem during the migration. Budget a one to two-hour meeting and one round of written comments. Second, run a quick dependency test. Take the two applications you are lining up for wave 1. Actually inspect their logs over a week, list every outgoing dependency (API calls, access to a shared database, and so on), and confirm with the teams that you have not missed anything. This test takes a day or two but often eliminates surprises that would cost a week of project time later. Third, document your prioritization in a simple, shared document: title, business context, the three assessment criteria, the resulting matrix, the four waves with their justifications, and the key assumptions ("we assume network bandwidth will be sufficient," "we rely on the database team to validate the data migrations"). This document serves as a contract with the other teams, and lets anyone wondering "why isn't app X in wave 1?" find a documented answer rather than an opinion. It takes two to three days to write, but it is worth ten later meetings spent explaining. Once these three steps are complete, you have a solid prioritization plan, accepted by leadership and understood by your teams. Only now can you connect the rest of the project (migration phases, detailed planning, resource allocation) to this stable foundation.