人工智能
与 Kiro 一起建立可重复的 PHP 到 Java 迁移引擎
当您的团队将一个成熟的PHP应用程序移动到Java时，会获得更强大的类型安全，更广泛的库支持，以及更可预测的缩放。 多年来用Laravel,Symfony，或"理论"搭建的PHP代码库在不明显的地方携带了商业规则，从口语特征到XML映射文件，因此结构相近的Java端口可以完整地编译，仍然表现不同。
显示这个帖子如何将PHP到Java的迁移从一次性的信仰飞跃转变为使用克洛的可衡量，可重复的过程。 Kiro是一个AI集成开发环境(IDE)，它将一个AI agent与你的代码库相配，在循环中运行多步工程任务。 该方法以可重复使用的发动机为中心：共享方法、机械发现扫描仪和八相工作流程。 此引擎将原始的PHP应用程序视为规格并拒绝宣布Java端口正确，直到对等的取用验证。
先决条件
在开始之前，你需要：
- 熟悉PHP(Laravel/口语或同音/口语)。 Java知识(Spring Boot, JPA)帮助您审查生成的输出，但引擎为您生产了平庸的Java，所以您不需要自己在Java中重写应用程序。
- 基罗工作区，可获取技能和指导文件。
- PHP 8.0或更新机器运行发现扫描仪，Java 21与Maven为生成的"春靴"项目。
- 对移徙规划的基本理解(发现、翻译和验证)。
在这篇文章中你会学到什么
你从一个开放的寄存器开始，这样你就可以自己运行引擎而不是读取。 引擎所知道的一切都生活在一小组技能文件里，有了这些文件，你可以用一个以上的方式运行同样的方法。
运行引擎的两种方式：基罗和AWS变形
这里的一切被包装为技能文件：版本的Markdown能力包将迁移方法(php-to-java-migration)和发现扫描仪工作流程(php-model-discovery)编码。 因为知识生活在文档而不是任何一种工具中，所以你可以以两种方式运行同样的方法。
方法 1: Kiro，交互式开发者即时开发
Kiro 带来一个AI agent进入你的编辑器，以一步步地驱动一个迁移。 打开寄存器根作为 Kiro 工作空间，当您要求 Kiro 迁移 PHP 应用程序时，技能会自动激活。 基罗然后用明确的批准门走出八相工作流程，所以你审查发现清单，批准规则书，并在下一个开始前在每个阶段签名。 这是这篇文章中每个例子所用的模式。
方法2:AWS 变换、代理和组合规模
AWS Transform是用于大规模迁移和现代化的AWS代理AI服务，现在它与基罗本土融合。 通过这种整合，您可以将AWS Transform的相同技能文件交给管理交互式基罗会话，因此在翻译前发现，作为裁判的等同利用，以及‘固定回路，而不是代码'适用于自主运行。
当每个路径适合
- 控制与自主：先用克洛通过代码：运行一个应用程序上的技巧，读出生成的Java，并运行测试。 AWS Transform在检查站检讨时
- 规模和新颖性：Kiro一次处理一个应用程序，并适用先天框架。 AWS 时速变形作为并行任务运行许多应用程序。
- 共享反馈回路：两条路径读取相同的技能文件，因此基洛所制作的每个规则书修补都会改进下个AWS Transform运行，反之亦然。
解决方案概览：一个共享的大脑，许多项目
发动机是围绕一个单一的原则组织起来的：一个共享的大脑，许多项目。 要打开它，在本地复制寄存器，然后在基罗打开一个文件夹并选择寄存器根(包含.kiro/的文件夹). Kiro 自动装入技能和引导
如下图所示，工作空间将共享的方法层与使用它的各个项目分开。 顶端是每个项目所借鉴的全球.kiro/层。 它的下方坐落着每个项目文件夹，每个文件夹都有自己的PHP源，Java输出，以及规格子文件夹。
这些相同的共享技能文件可以两种不同的方式运行，如下图所示。 相同的"八相","等同第一"管线可以由基罗(交互，一次一个应用)来驱动，也可以由AWS Transform(代理，以组合规模)来驱动，两者都可以将PHP源转换为等同可验证的Spring Boot Java.
.kiro/下的共享全球层拥有两个技能，即php-模型-发现(扫描仪)和php- to-java-迁移(八相游戏本)，外加核心-工作流程。 md 引导文件。 每个project文件夹都持有自己的PHP源，Java输出，和 spec子文件夹在.kiro/specs/下，因此一旦让每个项目继承收益，便会改进方法。
翻译前的发现
在扫描仪运行之前
如下图所示，扫描仪工作在一个没有依赖性的单行道上。 它在源代码上应用了3个发现策略，并发布了一个JSON清单，任何模糊的路由都到一个审查-旗下排队供人类解决。
扫描仪正在发现- models. php，一个单一文件，无依赖的 PHP 命令行工具，不执行目标代码。 它只读取源文本作为符号，所以它与您选择的应用程序相对应，不管其依赖性是否安装了。 它在每次扫描上运行了三种策略：口语模型发现(走出阶级继承链到Illuminate\Database\Elogueent\Model)，理论属性检测(#[ORM\实体]属性)，和ORM XML映射(外部 *.orm.xml文件). 输出为JSON单列。 一个模型[]阵列携带每个字段，铸造，关系，和能见度规则，每个条目都出现一个旗帜[]阵列。 扫描仪标出模糊而非猜测例如，从运行时表达式所构建的可充值列表会成为一面平版英语旗帜，而该旗帜列表是人类评论队列。
平等第一管道
0阶段正在准备：它运行扫描仪并组装存货。 然后，前三个阶段集中了人的专门知识。 第1阶段在Java写出之前构建了等效的被套用，针对PHP原版和Java端口重放请求/应答对。 牵引装置必须通过工作 PHP，当您故意断接它时失败，因为缺失注射断接的牵引装置是不可信的。 第二阶段是规则手册和漏洞清单的种子(RULEBOOK.md、GAP INVENTORY.md)，第三阶段是对照具有代表性的文件进行压力测试，然后在整个应用程序中执行。
前四个阶段集中了人类的专门知识。 0阶段运行扫描仪并组装存货。 第1阶段在Java写出之前构建了等效的被套用，针对PHP原版和Java端口重放请求/应答对。 牵引装置必须通过工作 PHP，当您故意断接它时失败，因为缺失注射断接的牵引装置是不可信的。 第二阶段是规则手册和漏洞清单的种子(RULEBOOK.md、GAP INVENTORY.md)，第三阶段是对照具有代表性的文件进行压力测试，然后在整个应用程序中执行。
相机 4-8 主要是自驾回路：第四阶段脚手架工程，第五阶段从出货单翻译出数据模型，第六阶段翻译出I/O层(路由变为控制器，中间软件变为过滤器，验证变为附加说明的数据传输对象)，第七阶段在分批中转换出业务逻辑，第八阶段证明对调和削减的对等。 环相通有两条原则。 首先，PHP代码是规格：当裁判同意时会完成端口，或者每次不匹配都会被记录为经批准的更改。 其次，你修补了循环，而不是代码，修正了规则书，并重生而不是手拍。
走过：从口才到春靴
laravel-elopet-sample项目是一个工作上，有界限的例子：开源 Laravel应用程序的只读切片，有"书","章","页"等用户模型被迁移到Java 21上的"Spring Boot" 3.4.1上并有"Maven"和一个"内相"H2数据库。
从PHP到Spring Boot的绘图是机械的和可追踪的，如下图所示。 左图上每个显示条目到右侧的Java构造，生成生成的应用程序切片的分层运行时架构。
映射是机械的，可以追溯到出品：一个PHP命名空间成为了Java软件包，一个口号模型成为了JPA@实体，有许多并且属于关系成为了@OneToMany和@ManyToOne，口号查询范围成为了Spring Data仓库方法。 显示在序列化方面的学科是：html、markdown和text 夹克@JsonIgnore，因为清单在Page的$dden列表中记录了它们，而Book的描述却刻意没有。
坦率地说，37个模型中只有4个被移植，而且最重要的是，从未为这一片块建造过平等带，它称之为“最大的差距 ”。 记录其不足之处本身就是设计的一部分。
开始
完整的迁移引擎可以在PHP-to-Java迁移寄存器样本中找到。
用来：
- 清除存储器并打开其根作为您的 Kiro 工作空间( 打开一个文件夹并选择包含。 kiro/ 的文件夹)。 除了PHP 8.0+外，没有其他东西可以安装，用于扫描仪和用Maven的Java 21.
- 将 PHP 源获取到项目源- php/ 文件夹中。 README将用于对等的准确上游承诺标出，以便任何人都可以复制基线。
- 叫基罗把申请转移 php-to-java-migration技能自动激活，先运行扫描仪，在.kiro/specs/下生成一新光谱，并走出审批门。
- 对于一个代理运行，在相同的技能文件中点出AWS Transform，所以它的agents在您的组合中执行相同的方法。
方法自动检测Laravel,Symfony,CodeIgniter，和平面PHP，并扩展为添加：为新框架添加检测行和参考文献/<框架>至spring.md指南。 因为基罗和AWS Transform读取了相同的文件，所以它们一旦被精炼，就同时升级了两个引擎。
清理
如果您在此过程中部署了样本Spring Boot应用程序：
- 停止运行的Spring Boot应用程序(内膜H2数据库是麻黄的，不需要单独清理)。
- 如果不再需要，从您的工作空间中删除生成的 Java 项目文件夹。
- 发现扫描仪只产生JSON清单文件如果您不打算参考，请从工作目录中删除发现扫描仪的 JSON 清单。
- 没有AWS资源由迁移引擎本身提供，因此没有云资源可以去提供。
结论
我们演示了如何与基罗一起建造一个可重复的PHP到Java的迁移引擎，将大规模重写变成一个可测量的复合过程。 主要原则是：
- 翻译前的发现：一个机械扫描仪对每个模型、领域和关系进行清点，所以你不会猜测结构。
- 在代码前构建判断器：在Java第一行被写入之前定义的对等绳。
- 修复回路，而不是代码：当同一错误出现在文件之间时，修正规则书，并重生而不是手打。
- 一个共享的大脑：该方法一出，在各项目之间分享，并随着每次迁移而得到改进。
这些都不是PHP或Java特有的。 同样的形状也适用于其他迁移，这里的旧系统是唯一完整的规格。 切除样本 PHP 到 Ja
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
Build a repeatable PHP-to-Java migration engine with Kiro
When your team moves a mature PHP application to Java, you gain stronger type safety, broader library support, and more predictable scaling. A PHP codebase built over the years with Laravel, Symfony, or Doctrine carries business rules in places that are not obvious, from Eloquent traits to XML mapping files, so a structurally similar Java port can compile cleanly and still behave differently.
This post shows how to turn PHP-to-Java migration from a one-time leap of faith into a measurable, repeatable process using Kiro. Kiro is an AI integrated development environment (IDE) that pairs an AI agent with your codebase to run multi-step engineering tasks with you in the loop. The approach centers on a reusable engine: a shared methodology, a mechanical discovery scanner, and an eight-phase workflow. This engine treats the original PHP application as the specification and refuses to declare the Java port correct until a parity harness verifies it.
Prerequisites
Before getting started, you need:
- Familiarity with PHP (Laravel/Eloquent or Symfony/Doctrine). Java knowledge (Spring Boot, JPA) helps you review the generated output, but the engine produces idiomatic Java for you, so you don’t need to rewrite the application in Java yourself.
- A Kiro workspace with access to Skills and Steering files.
- PHP 8.0 or newer on the machine running the discovery scanner, and Java 21 with Maven for the generated Spring Boot projects.
- A basic understanding of migration planning (discovery, translation, and validation).
What you will learn in this post
You start with an open repository, so you can run the engine yourself rather than read about it. Everything the engine knows lives in a small set of skill files, and with those files, you can run the same methodology in more than one way.
Two ways to run the engine: Kiro and AWS Transform
Everything here is packaged as skill files: versioned Markdown capability packages that encode the migration methodology (php-to-java-migration) and the discovery scanner workflow (php-model-discovery). Because that knowledge lives in files rather than any one tool, you can run the same methodology in two ways.
Method 1: Kiro, interactive and developer-in-the-loop
Kiro brings an AI agent into your editor to drive a migration step by step. Open the repository root as a Kiro workspace and the skills activate automatically when you ask Kiro to migrate a PHP application. Kiro then walks the eight-phase workflow with explicit approval gates, so you review the discovery manifest, approve the rulebook, and sign off on each phase before the next begins. It’s the mode used for every example in this post.
Method 2: AWS Transform, agentic and at portfolio scale
AWS Transform is the AWS agentic AI service for large-scale migration and modernization, and it now integrates natively with Kiro. Through that integration, you can hand AWS Transform the same skill files that govern an interactive Kiro session, so discovery before translation, the parity harness as referee, and ‘fix the loop, not the code’ apply to an autonomous run.
When each path fits
- Control and autonomy: Use Kiro to work through the code first: run the skill on one application, read the generated Java, and run the tests. When you want to migrate more, AWS Transform runs the same methodology agentically with review at the checkpoints the skill defines.
- Scale and novelty: Kiro handles one application at a time and suits first-of-a-kind frameworks. AWS Transform runs many applications as parallel jobs.
- A shared feedback loop: Both paths read the same skill files, so every rulebook fix made in Kiro improves the next AWS Transform run, and vice versa.
Solution overview: One shared brain, many projects
The engine is organized around a single principle: one shared brain, many projects. To open it, clone the repository locally, then in Kiro open a folder and select the repository root (the folder containing .kiro/). Kiro loads the skills and steering automatically, with fuller steps in “Getting started.”
The workspace separates a shared methodology layer from the individual projects that use it, as shown in the following diagram. At the top is a global .kiro/ layer that every project draws on. Beneath it sit the per-project folders, each with its own PHP source, Java output, and specification sub-folder.
Those same shared skill files can be run in two different ways, shown in the following diagram. The identical eight-phase, parity-first pipeline can be driven either by Kiro (interactive, one application at a time) or by AWS Transform (agentic, at portfolio scale), and both convert PHP source into parity-verified Spring Boot Java.
A shared, global layer under .kiro/ holds two Skills, php-model-discovery (the scanner) and php-to-java-migration (the eight-phase playbook), plus the core-workflow.md Steering file. Each per-project folder holds its own PHP source, Java output, and spec sub-folder under .kiro/specs/, so improving the methodology once lets every project inherit the gain.
Discovery before translation
The single most important rule fires before anything else: Don’t read, guess at, or hand-translate a model or entity file until the scanner has run.
The scanner works in a single pass with no dependencies, as shown in the following diagram. It applies three discovery strategies to the source tokens and emits one JSON manifest, with anything ambiguous routed to a review-flag queue for a human to resolve.
The scanner is discover-models.php, a single-file, dependency-free PHP command-line tool that doesn’t execute the target code. It only reads source text as tokens, so it runs against apps of your choice whether its dependencies are installed. It runs three strategies on every scan: Eloquent model discovery (walking the class inheritance chain to Illuminate\Database\Eloquent\Model), Doctrine attribute detection (the #[ORM\Entity] attribute), and ORM XML mapping (external *.orm.xml files). The output is a single JSON manifest. A models[] array carries every field, cast, relationship, and visibility rule, and a flags[] array appears on every entry. The scanner flags ambiguity rather than guessing. For example, a $fillable list built from a runtime expression becomes a plain-English flag, and that flag list is the human review queue.
The parity-first pipeline
Phase 0 is preparatory: it runs the scanner and assembles the inventory. The first three phases then concentrate human expertise. Phase 1 builds the parity harness before Java is written, replaying request/response pairs against both the PHP original and the Java port. The harness must pass against working PHP and fail when you break it deliberately, because a harness that misses injected breakage is not trusted. Phase 2 seeds the rulebook and gap inventory (RULEBOOK.md, GAP_INVENTORY.md), and Phase 3 stress-tests it against representative files before committing it across the application.
The first four phases concentrate human expertise. Phase 0 runs the scanner and assembles the inventory. Phase 1 builds the parity harness before Java is written, replaying request/response pairs against both the PHP original and the Java port. The harness must pass against working PHP and fail when you break it deliberately, because a harness that misses injected breakage is not trusted. Phase 2 seeds the rulebook and gap inventory (RULEBOOK.md, GAP_INVENTORY.md), and Phase 3 stress-tests it against representative files before committing it across the application.
Phases 4–8 are mostly self-driving loops: Phase 4 scaffolds the project, Phase 5 translates the data model from the manifest, Phase 6 translates the I/O layer (routes become controllers, middleware becomes filters, validation becomes annotated data transfer objects), Phase 7 converts business logic in batches, and Phase 8 proves parity against the harness and cuts over. Two principles govern the loop. First, the PHP code is the specification: the port is done when the referee agrees, or each mismatch is logged as an approved change. Second, you fix the loop, not the code, amending the rulebook and regenerating rather than hand-patching.
Walkthrough: From Eloquent to Spring Boot
The laravel-eloquent-sample project is a working, bounded example: a read-only slice of an open source Laravel application, with the Book, Chapter, Page, and User models migrated to Spring Boot 3.4.1 on Java 21 with Maven and an in-memory H2 database.
The mapping from PHP to Spring Boot is mechanical and traceable, as shown in the following diagram. Each manifest entry on the left maps to a Java construct on the right, producing the layered runtime architecture of the generated application slice.
The mappings are mechanical and traceable back to the manifest: a PHP namespace becomes a Java package, an Eloquent model becomes a JPA @Entity, has Many and belongs to relationships become @OneToMany and @ManyToOne, and Eloquent query scopes become Spring Data repository methods. The discipline shows in serialization: html, markdown, and text carry @JsonIgnore because the manifest recorded them in Page’s $hidden list, while Book’s description deliberately doesn’t.
The spec is candid that only 4 of 37 models were ported and, most important, that the parity harness was never built for this slice, which it calls “the single biggest gap.” Documenting where it falls short is itself part of the design.
Getting started
The complete migration engine is available in the sample PHP-to-Java migration repository.
To use it:
- Clone the repository and open its root as your Kiro workspace (open a folder and select the folder containing .kiro/). Nothing to install beyond PHP 8.0+ for the scanner and Java 21 with Maven.
- Fetch the PHP source into the project’s source-php/ folder. The README pins the exact upstream commits used for parity so anyone can reproduce the baseline.
- Ask Kiro to migrate the application. The php-to-java-migration skill activates automatically, runs the scanner first, generates a fresh spec under .kiro/specs/, and walks you through the approval gates.
- For an agentic run, point AWS Transform at the same skill files, so its agents execute the identical methodology across your portfolio.
The methodology auto-detects Laravel, Symfony, CodeIgniter, and plain PHP, and extension is additive: add a detection row and a references/<framework>-to-spring.md guide for a new framework. Because Kiro and AWS Transform read the same files, refining them once upgrades both engines.
Clean up
If you deployed the sample Spring Boot application during this walkthrough:
- Stop the running Spring Boot application (the in-memory H2 database is ephemeral and requires no separate cleanup).
- Remove the generated Java project folder from your workspace if no longer needed.
- The discovery scanner produces only a JSON manifest file. Delete the discovery scanner’s JSON manifest from your working directory if you don’t plan to reference it.
- No AWS resources are provisioned by the migration engine itself, so there are no cloud resources to deprovision.
Conclusion
We showed how to build a repeatable PHP-to-Java migration engine with Kiro that turns large-scale rewrites into a measurable, compounding process. The key principles are:
- Discovery before translation: A mechanical scanner inventories every model, field, and relationship, so you don’t guess at structure.
- Build the judge before the code: A parity harness defines done before the first line of Java is written.
- Fix the loop, not the code: When the same mistake appears across files, amend the rulebook and regenerate rather than hand-patching.
- One shared brain: The methodology is written once, shared across projects, and improves with each migration.
None of this is specific to PHP or Java. The same shape applies to other migrations where the old system is the only complete specification. Clone the sample PHP-to-Ja
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.