Hey there! Since you're new to the WildFly ecosystem and aren't a developer, I'll keep this guide practical, step-by-step, and focused on minimizing complexity for your migration.

1. Recommended WildFly Version to Use #

JBoss EAP 6.4 is based on WildFly 8.x under the hood, but for a smoother migration with better compatibility and support, I recommend WildFly 10.x as your first target. It’s the closest upstream release to EAP 6.4, supports Java 8 (which EAP 6.4 also uses), and requires the least amount of configuration/behavior adjustments. Once you have this working, you can optionally upgrade to newer WildFly versions later (like 11.x or 26.x, the latest LTS) if needed.

2. Step-by-Step Migration Process #

Step 1: Prepare Your WildFly Environment #

• Download the WildFly 10.x package, extract it to a directory on your server.
• Ensure your JAVA_HOME points to Java 8 (same as you used for EAP 6.4) – WildFly 10 doesn’t support older Java versions, and newer ones might cause compatibility issues initially.
• Start WildFly once to generate default configuration files: run bin/standalone.sh (Linux) or bin/standalone.bat (Windows), wait for it to fully start, then shut it down with Ctrl+C.

Step 2: Initial Application Test Deployment #

• Take your existing WAR/EAR file from EAP 6.4 and copy it to WildFly’s standalone/deployments directory.
• Start WildFly again and check the standalone/log/server.log file for errors. This will immediately flag obvious issues like missing dependencies or incompatible APIs.

Step 3: Migrate Configuration (standalone.xml) #

This is the most critical part. You can automate most of it with a built-in tool, or adjust manually if preferred:

Option A: Automated Migration Tool (Recommended for Non-Developers)

WildFly includes a jboss-server-migration tool that converts EAP 6.4 configurations to WildFly-compatible settings. Here’s how to use it:

1. Shut down both EAP 6.4 and WildFly.
2. Run the tool from your WildFly bin directory:

   ./jboss-server-migration.sh --source=/path/to/jboss-eap-6.4/standalone --target=/path/to/wildfly-10/standalone
   

   (For Windows, use jboss-server-migration.bat)
3. The tool will automatically update your WildFly standalone.xml with datasources, security domains, system properties, and other settings from EAP 6.4. It will log any changes or unresolved items for your review.

Option B: Manual Configuration Adjustments

If you prefer manual work, focus on these key areas:

• Datasources: Copy your <datasource> and <driver> definitions from EAP 6.4’s standalone.xml to WildFly’s. Note the namespace version difference (WildFly 10 uses urn:jboss:domain:datasources:4.0 vs EAP 6.4’s 1.2), but core settings like URL, username, and driver class stay the same. If your JDBC driver was an EAP module, copy the module folder from jboss-eap-6.4/modules to wildfly-10/modules.
• System Properties: Any <system-property> entries from EAP’s config can be directly pasted into WildFly’s standalone.xml under the <system-properties> section.
• Security Domains: Most security domain configurations (for authentication/authorization) are compatible, but double-check the namespace version (WildFly 10 uses urn:jboss:domain:security:2.0 vs EAP 6.4’s 1.2).
• JMS Configuration: EAP 6.4 uses HornetQ, while WildFly 10 uses ActiveMQ Artemis. The migration tool handles this conversion automatically; if doing manually, recreate queues/topics under the <messaging-activemq> subsystem instead of <hornetq-server>.

Step 4: Resolve Deployment Issues #

If your app fails to deploy, check server.log for common errors:

• "Missing module": Copy the required module from EAP to WildFly, or package the dependency directly into your WAR/EAR file.
• "Incompatible API": If the app uses EAP-specific internal classes (like org.jboss.as.*), you might need help from your development team for small adjustments – but this is rare for standard Java EE apps.

Step 5: Functional Testing #

Once the app deploys successfully, test all core features (user login, database interactions, messaging if used) to ensure they work exactly as they did on EAP 6.4.

3. Will You Need Development Work? #

For standard Java EE 6 applications (which EAP 6.4 supports), you likely won’t need any code changes. WildFly 10 is fully compatible with Java EE 6, and most apps run without modifications.

Development help might be needed only if:

• The app uses EAP-specific proprietary APIs (not standard Java EE).
• The app relies on custom EAP modules that can’t be easily migrated to WildFly.
• You’re jumping directly to a newer WildFly version (like 26.x) that uses Java EE 8/Jakarta EE – starting with WildFly 10 avoids this issue.

4. Key Migration Tips #

• Always test in a non-production environment first – never migrate directly to production without validating everything.
• Keep the default WildFly standalone.xml as a backup, so you can revert if something breaks.
• If stuck on an error, focus on the exact message in server.log – it almost always tells you exactly what’s missing or misconfigured.
• For JMS migrations, use the automated tool whenever possible – converting HornetQ to ActiveMQ Artemis manually can be tricky.

内容的提问来源于stack exchange，提问作者Prasanna Weerasinghe