I tried analyzing a FuelPHP system before migration with AWS Transform's VS Code extension

Introduction

As of April 2026, AWS Transform is now available as a VS Code extension.

https://aws.amazon.com/jp/about-aws/whats-new/2026/04/aws-transform-kiro-vscode/

Until now, AWS Transform custom was a tool operated using the atx CLI, but with the release of the VS Code extension (AWS Transform - Visual Studio Marketplace), you can now run jobs directly from within VS Code.

I tried it out right away to see what it's like.

Additionally, I also tried the comprehensive codebase analysis transformation TD (Transform Definition) of AWS Transform custom.
This is a feature that statically analyzes your codebase and documents information for migration.
If you're interested in this feature, please continue reading.

https://aws.amazon.com/jp/about-aws/whats-new/2026/03/transform-custom-new-codebase-analysis/

Summary of this article

• AWS Transform VS Code extension has been released. The actual processing runs with AI agents like Claude Code operating the atx CLI
• Running comprehensive codebase analysis on a FuelPHP codebase automatically generated 32 files of documentation
• The migration plan is output by phase with code examples, and test cases and validation criteria are automatically generated

Prerequisites

The VS Code extension uses AI agents for the actual code transformation and analysis. You need to have one of the following installed and available for use in VS Code:

• Claude Code ← The environment used in this article
• Amazon Q
• GitHub Copilot
• Cline
• OpenAI Codex

https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.aws-transform-plugin

You need to have the AWS Transform command (atx) installed and AWS credential keys capable of running AWS Transform. For details on command installation, please refer to this blog:

https://dev.classmethod.jp/articles/aws-transform-custom-ga/

The VS Code extension doesn't directly execute atx but generates and sends prompts to the AI agent. The agent follows the procedures in the SKILL.md included with the extension to execute the atx command. This is the structure:

It looks something like this:

GitHub repository

The target of our analysis is a FuelPHP Wiki application.

https://github.com/rednes/aws-transform-php-sample

I used the same one as in a previous blog where I did a FuelPHP to Laravel migration using the atx CLI. For more details, please check this blog:

https://dev.classmethod.jp/articles/aws-transform-custom-fuelphp-to-laravel-migration/

Installing the VS Code extension

Search for AWS Transform in the extensions panel and install the extension.

Eventually, the AI agent will use the atx command with AWS authentication credentials on VS Code.
Therefore, you need to make AWS authentication credentials accessible from VS Code in some way.

I chose to generate temporary AWS authentication credentials, store them in terminal environment variables, and launch Visual Studio Code using the CLI command to share the terminal environment variables.

• Reference: Command Line Interface (CLI)

Using the AWS Transform extension

Click on the AWS Transform icon panel to open the screen.

Select Local for the Execution Mode.

Click Browser for Folders... to add the target repository you want to plan migration for.
In this case, I selected aws-transform-php-sample that I had already cloned locally.

For Additional Plan Context, I added the following text:

Migrate an application from FuelPHP 1.8 / PHP 7.4 to Laravel 13 / PHP 8.4.

For Send to, I specified Claude Code.

After entering everything, when I pressed the Send to Agent button, the screen moved to Claude Code, and the request was written in the chat.
It seems this is how it's done through the AI agent.

Looking briefly at the request, it seems there's a skill definition file for AWS Transform in the VS Code plugin, and it says to execute the atx command according to that. I've included the full text for reference.

I want to run an AWS Transform custom transformation.

Repositories:
Direct paths:
- /Users/xxxx/github/aws-transform-php-sample

Additional plan context (user-provided):
```

Migrate an application from FuelPHP 1.8 / PHP 7.4 to Laravel 13 / PHP 8.4.

```

CRITICAL: Before doing anything, read the skill instructions at /Users/xxxx/.vscode/extensions/amazonwebservices.aws-transform-plugin-1.0.0/resources/atx-transform/SKILL.md. That file references detailed procedure documents in the same directory — you MUST read and follow them exactly. These files may be located outside of the current working directory — you must find a way to read them anyway. These reference files are your authoritative source of truth for every step of the process. Do not improvise or skip steps. The selected execution mode is Local (ATX CLI on my machine) -- ensure that this choice is respected.

During local execution, periodically list the artifacts directory at ~/.aws/atx/custom/<conversation-id>/artifacts/ and open any new files in the current editor window as they appear (do not launch a new IDE instance). Track which files you have already opened to avoid duplicates.

When executed, Claude Code conducted various investigations for migration and presented two options:

• Create a custom TD and proceed with migration
• Run a codebase analysis to understand the overall picture of migration

It also generated a transformation analysis report. I'm including the full text for reference.

Transformation Analysis Report
I've analyzed your repository:

Repository Information
Name: aws-transform-php-sample
Path: /Users/xxxx/github/aws-transform-php-sample
Framework: FuelPHP 1.8
PHP Requirements: PHP 5.4+ (based on composer.json)
Transformation Goal
Migration from FuelPHP 1.8 / PHP 7.4 → Laravel 13 / PHP 8.4

Available Transformation Definitions (TDs)
I've checked the currently available TDs in AWS Transform, but there are no TDs specifically for PHP framework migration (FuelPHP → Laravel).

Available TDs include:

Java version upgrades, AWS SDK migrations
Python version upgrades, boto2→boto3 migrations
Node.js version upgrades, AWS SDK migrations
Angular, Vue.js version upgrades
Codebase analysis, performance optimization
Recommended Approach
PHP framework migration is a complex transformation that requires creating a custom transformation definition (TD). You have the following options:

1. Create a custom TD

You can run the following command in a new terminal to create a TD through an interactive session:

atx -t
In this session, you'll describe transformation details such as:

"Migrate a FuelPHP 1.8 application to Laravel 13"
Transforming routes, controllers, models, and views
Migrating configuration files
Updating dependencies
Ensuring PHP 8.4 compatibility
The ATX CLI will guide you through creating and publishing the transformation definition. Once published, you can return to this session, and I can automatically detect the new TD and execute the transformation.

2. Run a comprehensive codebase analysis

You can also use the existing TD AWS/comprehensive-codebase-analysis to first perform a detailed analysis of your codebase. This analysis will help you understand the overall scope of work needed for migration:

Documentation of architecture
Identification of technical debt
Extraction of FuelPHP-specific patterns and dependencies
Which option would you prefer?

Proceed with creating a custom TD
Run a codebase analysis first to understand the overall migration picture
Consider other approaches

It seems there's a dedicated TD (AWS/comprehensive-codebase-analysis) for comprehensive codebase analysis in AWS Transform custom.

For this time, I'll try this comprehensive codebase analysis as well.

What is comprehensive codebase analysis?

The AWS/comprehensive-codebase-analysis transformation of AWS Transform custom is a TD that statically analyzes the target codebase and generates structured documentation including architecture, technical debt, code metrics, reference documents, migration plans, and diagrams.

• Reference: AWS Transform custom announces general availability of automated codebase analysis
• Reference: AWS Transform: Comprehensive Codebase Analysis for Modernization | Migration & Modernization

Trying AWS Transform's comprehensive codebase analysis

When I asked Claude Code to analyze the codebase, it prompted me to confirm the transformation plan.

Transformation Plan Confirmation
Transformation Definition (TD): AWS/comprehensive-codebase-analysis

Repository: /Users/xxxx/github/aws-transform-php-sample

Execution Mode: Local (ATX CLI)

Additional Plan Context: "Analysis for migration from FuelPHP 1.8 to Laravel 13, with focus on structure and dependencies of routing, controllers, models, and views."

This analysis will provide:

Project architecture and structure
Usage of FuelPHP-specific patterns and features
Technical debt and areas for improvement
Detailed insights into necessary migration work
Do you want to proceed with this plan?

After approval, Claude Code executed the atx command and periodically checked the artifacts.

As shown in the following screen, I was occasionally asked for permission to execute commands by Claude Code.

After about 40 minutes of granting permissions and monitoring, the execution completed.

I was informed that a comprehensive documentation had been created in ./ATXDocumentation.

Let's look at the created documentation in the next chapter.

For reference, I'm including the full completion report.

✅ AWS Transform Custom Transformation Completed Successfully
Comprehensive codebase analysis of the FuelPHP 1.8 application completed successfully.

📊 Execution Summary
Transformation Definition (TD): AWS/comprehensive-codebase-analysis

Conversation ID: 20260415_033739_b38847db

Exit Code: 0 (Success)

Generated Documents: 32 Markdown files

📁 Generated Document Structure
ATXDocumentation is placed in two locations:

Project root: /Users/xxxx/github/aws-transform-php-sample/ATXDocumentation/
User directory: ~/.aws/atx/custom/20260415_033739_b38847db/ATXDocumentation/
🎯 Key Analysis Findings
1. Technical Debt Key Findings (technical-debt-report.md)
High Severity Issues:

FuelPHP 1.8.2: EOL/abandoned framework (no updates since 2019)
PHP 7.4: EOL (support ended November 28, 2022)
PHP 5.4+ compatibility target: Very old code patterns
Medium Severity Issues:

monolog 1.x, phpseclib 2.x: EOL libraries
Bootstrap 3.x: Outdated UI framework
2. Migration Plan (migration/component-order.md)
Recommended migration strategy: Greenfield rewrite (approx. 321 lines of custom code)

Migration phases:

Laravel 13 project setup (PHP 8.2+ requirement)
Database layer migration (schema.sql → Laravel migrations)
Model layer (Model_Page → Eloquent Page)
Routing layer (FuelPHP routes → Laravel routes/web.php)
Controller layer (Controller_Wiki → WikiController)
View layer (PHP views → Blade templates)
Presenter layer (Presenter → View Composer)
Static assets (Bootstrap 3 → Bootstrap 5/Tailwind)
3. Architecture Analysis
Pattern: MVC + Presenter (ViewModel)
Database: MySQL 8.0, single table pages
ORM: FuelPHP ORM (using Observer_CreatedAt, Observer_UpdatedAt)
View engine: PHP templates (Bootstrap 3-based)
📖 Main Document Sections
Architecture: System overview, components, dependencies, patterns
Behavior: Business logic, workflows, error handling
Diagrams: Structural diagrams, behavioral diagrams, architecture diagrams (text-based)
Migration: Component order, test specifications, validation criteria
Technical Debt: Summary, outdated components, remediation plans
Reference: API reference, data models, program structure
Analysis: Code metrics, complexity analysis, security patterns
Specialized: Database patterns, UI components
🚀 Next Steps
Use this documentation to:

Refine the migration plan to Laravel 13
Share and discuss with team members
Prioritize migration work
Gradually address technical debt
All documents can be navigated from ATXDocumentation/README.md.

Looking at the generated documentation

The documentation generated by the analysis consists of 32 files.
All are output in English.

.
├── README.md                        # Table of contents/Quick start
├── project-overview.md              # Tech stack/Dependencies
├── technical-debt-report.md         # ⚠ Technical debt report (important)
│
├── architecture/                    # System architecture/Dependencies
├── behavior/                        # ★ Early Access — Business logic/Flows
├── diagrams/                        # Component diagrams/Sequence diagrams/Architecture diagrams
├── technical-debt/                  # EOL analysis/Improvement plans
├── migration/                       # FuelPHP → Laravel 13 migration order/Tests
├── reference/                       # API/Data models/Interfaces
├── analysis/                        # Code metrics/Complexity/Security
└── specialized/                     # DB patterns/UI components

The created documents are publicly available on GitHub, so please check here for details.

• aws-transform-php-sample/ATXDocumentation/README.md · rednes/aws-transform-php-sample

Since reading English can be tough, I also had Kiro CLI (AWS's AI agent) create a Japanese version.

• aws-transform-php-sample/ATXDocumentation_jp/README.md · rednes/aws-transform-php-sample

Let me introduce some of the content.

Request flow is presented as a diagram

diagrams/architecture/system-context.md includes a request flow diagram that visualizes the FuelPHP request lifecycle.

┌──────┐    ┌─────────────────────────────────────────────────────────────┐
│      │    │                    FuelPHP Application                       │
│      │    │                                                             │
│  B   │    │  ┌──────────┐    ┌───────────┐    ┌─────────┐              │
│  r   │──→ │  │  index.  │──→ │ bootstrap │──→ │  Fuel   │              │
│  o   │    │  │  php     │    │  .php     │    │  ::init │              │
│  w   │    │  └──────────┘    └───────────┘    └────┬────┘              │
│  s   │    │                                        │                    │
│  e   │    │                                   ┌────▼────┐               │
│  r   │    │                                   │ Router  │               │
│      │    │                                   └────┬────┘               │
│      │    │              _root_ → wiki/index       │                    │
│      │    │              convention → wiki/*        │                    │
│      │    │                                   ┌────▼──────────────┐     │
│      │    │                                   │  Controller_Wiki  │     │
│      │    │                                   │  action_*()       │     │
│      │    │                                   └───┬──────────┬───┘     │
│      │    │                                       │          │          │
│      │    │                              ┌────────▼──┐  ┌───▼──────┐   │
│      │    │                              │ Model_Page│  │Presenter │   │
│      │    │                              │ (ORM)     │  │→ View    │   │
│      │    │                              └─────┬─────┘  └──────────┘   │
│      │    │                                    │                        │
│      │←── │                              ┌─────▼─────┐                  │
│      │    │                              │  MySQL     │                  │
│      │    │                              │  (PDO)     │                  │
└──────┘    │                              └───────────┘                  │
            └─────────────────────────────────────────────────────────────┘

Explicit routing rules (_root_ → wiki/index), conventional routing rules (convention → wiki/*), and the flow of Presenter to View are illustrated.
This seems helpful for grasping the overall picture.

Everything from DB queries to UI screen composition is included

The specialized/ folder contains dedicated documentation for DB patterns and UI components.

specialized/database-patterns.md summarizes SQL queries executed by the app for each operation with source file line numbers, mapping FuelPHP ORM code, generated SQL, and equivalent Laravel code. For example, page creation (INSERT) was output like this:

Page INSERT (Create)
Source: controller/wiki.php, lines 44-48

// FuelPHP
$page = Model_Page::forge(array(
    'title' => $title,
    'content' => $content,
));
$page->save();

-- Generated SQL
INSERT INTO `pages` (`title`, `content`, `created_at`, `updated_at`)
VALUES (?, ?, ?, ?)

// Laravel equivalent
Page::create($request->validated());

SELECT, UPDATE, DELETE are also output in the same format.

specialized/ui-components.md even includes ASCII art wireframes.

┌──────────────────────────────────────────────────────┐
│  [+ Create new page] (btn-add)                       │
│                                                      │
│  ┌──────────────────────────────────────────────────┐│
│  │  Page List                          N pages      ││
│  ├──────────────────────────────────────────────────┤│
│  │  📄 Page Title                    [Edit] [Delete] ││
│  │     Updated: 2024/01/15 14:30                    ││
│  └──────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────┘

JavaScript implementation is also summarized in one sentence as "Only native confirm() dialog for delete confirmation. No AJAX," which helps understand what needs to be considered during migration.

Migration plan includes code examples for each phase

migration/component-order.md contained an automatically generated 8-phase migration plan.

Each phase includes mapping tables and code examples.

DB Migration (Phase 2)

Phase 2's DB migration was output like this. The mapping to the original schema is written in comments:

Schema::create('pages', function (Blueprint $table) {
    $table->id();                           // ← id INT AUTO_INCREMENT PK
    $table->string('title', 255);           // ← title VARCHAR(255) NOT NULL
    $table->text('content')->nullable();    // ← content TEXT (nullable)
    $table->timestamps();                   // ← created_at, updated_at (TIMESTAMP)
});

Routing (Phase 4)

FuelPHP is a framework where URLs are implicitly determined by method name conventions (e.g., the action_index() method automatically corresponds to GET /wiki). The AI decoded these conventions and generated a mapping table that identifies the URL and HTTP method corresponding to each action.

Looking at the last line, it accurately identified that the delete operation is implemented using GET, and the migration plan includes changing it to the DELETE method.

Laravel has a helper called Route::resource() that registers all routes needed for CRUD operations at once, and all the mappings above can be covered by this one line:

Route::resource('wiki', WikiController::class)->parameters(['wiki' => 'page']);

Views (Phase 6)

FuelPHP has an intermediate layer called Presenter between Controller and View, designed to handle display logic like date formatting. The migration plan shows the procedure for eliminating this layer and integrating it into the Controller, and also lists the changes to view files.

Test cases for migration verification are automatically generated

migration/test-specifications.md contained automatically generated test cases that can be used for verification after migration, based on the existing application's behavior.

Items marked new are behaviors that will be achieved with the Laravel migration but weren't present in FuelPHP. The content is aware of the differences between pre- and post-migration.

migration/validation-criteria.md also defines success criteria in four categories: functionality, security, technical, and UI/UX. For example, security criteria:

Since what constitutes "completion" of the migration is clearly articulated, this can be used directly as a checklist.

About the conclusion "Recommended conversion: none"

At the beginning of the technical debt report, it was written:

Recommended Transformation: none

There are no AWS managed Transformations applicable to this FuelPHP 1.8.2 PHP codebase. Available AWS Transformations cover Java, Node.js, Python, Angular, and Vue.js ecosystems, but do not include migration of PHP frameworks.

You might think "so it can't be used," but in the previous article using the atx CLI, we were actually able to convert from FuelPHP to Laravel.

This is not a contradiction, but means that AWS managed transformations (pre-prepared rule sets) do not include PHP framework migration. In atx CLI's interactive mode, you can migrate PHP applications because you create a new custom transformation definition before execution.

In summary:

Conclusion

My impression after trying the AWS Transform codebase analysis with the VS Code extension.

The VS Code extension is a system that operates AWS Transform using AI agents like Claude Code.

I thought it was an interesting system that makes AWS Transform easier to use, similar to a sub-agent for Claude Code.

Additionally, I found the comprehensive code analysis TD from AWS Transform custom genuinely helpful, as having this much information automatically generated before migration is valuable. Static analysis for documenting web systems with little documentation can help organize "where to start."

I feel there is high value in using this tool when you want to "quickly create a migration roadmap" or "understand the overall picture of the current code."

This test was with a small FuelPHP codebase, but the benefits of this analysis would likely increase with codebases of tens of thousands of lines.

I hope this blog is helpful to someone.