AWS Migration Assessment: What Can Actually Be Automated?

Most AWS migration assessments still look like consulting theater: interviews, spreadsheets, and a slide deck that expires the week after the readout.

The expensive part of that process is rarely the architecture conversation. The expensive part is paying engineers to type what software can already observe.

Level Up's position is simple: automate the mechanical work, then spend engineering time on the decisions that actually require judgment. The automated AWS migration assessment is built around that split.

What software can collect reliably

These inputs are repetitive, structured, and cheap to refresh:

• Host, OS, package, and service inventory
• Existing Terraform and Ansible inventories
• Database engines, versions, extensions, and storage
• Listening ports, process lists, and scheduled jobs
• Known dependency edges from config, connection strings, and DNS
• Utilization samples where agents or APIs already exist

Ansible is a good discovery substrate because it already has the credentials, inventory model, and modules to ask a machine what it is. Terraform is a good planning substrate because it already describes the intended target.

- name: Collect migration evidence from Linux hosts
  hosts: all
  gather_facts: true
  tasks:
    - name: Capture listening ports
      ansible.builtin.command: ss -lntu
      register: listening_ports
      changed_when: false

    - name: Capture installed services
      ansible.builtin.service_facts:

    - name: Write a machine-readable host record
      ansible.builtin.copy:
        dest: "/tmp/assessment/{{ inventory_hostname }}.json"
        content: "{{ {'hostname': inventory_hostname, 'os': ansible_facts['distribution'], 'ports': listening_ports.stdout_lines, 'services': services} | to_nice_json }}"

That is evidence. It is not a recommendation.

What software can infer — with a confidence score

Once evidence exists, deterministic rules can propose:

• 7 Rs dispositions (rehost, replatform, retain, and so on)
• AWS service candidates (EC2, RDS, FSx, ECS, Transfer Family)
• Wave grouping from a dependency graph
• Terraform and Ansible candidates
• A first-pass cost model with assumptions labeled

The important word is propose. A recommendation should be a chain:

fact → inference → recommendation → human decision

If PostgreSQL 15 is observed, storage is 380 GB, and no unsupported extensions are present, replatforming to Amazon RDS for PostgreSQL is a high-confidence suggestion. It is still a suggestion. License, cutover window, and business timing stay with people.

What should stay with engineers

Do not automate these into a black box:

• Ambiguous or inferred-only dependencies
• Plant-floor latency and OT constraints
• License mobility and contractual risk
• Which exceptions are acceptable
• Cutover sequence when the graph is incomplete
• Whether to modernize now or migrate first

This is why we do not describe the assessment as an AI architect. Software gives migration engineers leverage. It does not replace them.

What the output should be

If the assessment only produces a PDF, you still have a documentation project.

A useful assessment produces:

• Inventory
• Workload map
• Dependency graph
• Disposition and target architecture
• Cost and risk
• Migration waves
• An executable backlog

See the Acme Manufacturing example for the shape of those artifacts. Or run the open-source assessment yourself.

The report is not the system of record. The evidence is.