If you are completely new to FWD, the best way to gain a quick understanding is to watch a few of the demonstration videos.

If you have a character mode application, start with the FWD ChUI Demo. If you have a graphical application, start with the FWD GUI Demo. If your application runs primarily in batch mode or in Appserver mode, either demo will do, just to get a feel for some of the ground FWD covers.

Next, watch the How FWD Conversion Works video to see the conversion process in action.

Download the FWD project from the FWD downloads wiki page and follow the instructions there to download its dependencies. Follow the instructions there to build FWD.

Download either the ChUI demo application or the GUI demo application, depending on which matches your situation. If you have an application with no user interface (just batch or Appserver), you will be better off starting with the ChUI demo.

The demo applications serve two purposes. Firstly, they provide working sample projects, so you can see the FWD technology converting a full (albeit small) Progress application, and running the converted result in Java, against a new database. Secondly, they provide a template for you to get your own conversion project up and running.

At this point, just get the sample code converting and running, so you know you've got a functional baseline project. Also, generate and review the standard reports and look through them. Follow the instructions in the wiki from which you downloaded the respective ChUI or GUI demo application.

So, now you've gotten one of the samples successfully converted, built, and running in Java. You probably have a lot of questions and you may be anxious to try this out with your own ABL code. This is a good time to look over the FWD documentation. The best place to start for practical guidance on a new conversion project is the FWD Conversion Handbook. The Methodology chapter contains very similar information to what you are reading now, but with a lot more detail and references for further reading.

You also should review carefully the summary of supported ABL features to get an early idea if there are any ABL features you know your application uses which are not yet supported by FWD.

Before you embark on converting your application, you'll need to do some gap analysis to determine whether your application uses ABL features not yet supported by FWD. Don't be surprised if it does; FWD covers a lot of ground (most of the basics and a lot more), but the ABL is big and complicated. Any non-trivial application developed over a long period of time is likely either to use some ABL features not yet implemented, or to use some supported features in a way not currently anticipated by FWD.

At this phase, you want to produce detailed reports about your application to see what's inside. Although not yet fully implemented across all features, there is some automated gap analysis directly available in the standard reports produced by the FWD Analytics tools. This will help flag potential problem areas quickly, using a color-coded system to indicate the level of support for certain language features.

Using the framework provided by the sample project you built, follow the instructions in the FWD Analytics documentation.

Once you have gotten through the front end conversion and report generation processes, review in particular the reports which include automated gap analysis to get a sense for the coverage in FWD for the features your application uses.

By this time, you're actually beyond the "Getting Started" phase and well into the implementation of a conversion project. Start small by isolating a well-scoped subset of your code as a proof of concept. Avoid features that are known to not yet be implemented. Generally, the full schema information can be used, but you'll want to cut out any code with features noted as unsupported in the summary of supported ABL features and which were flagged as unsupported in the reports' gap analysis.

Use the framework provided by the sample project you built, and follow the documentation in the FWD Conversion Handbook to convert your reduced code set. As noted earlier, the automated gap analysis is not yet complete, so you likely will still hit unsupported areas. To address these, you can either further pare down your code set to omit these uses, or get help adding these features (see below), if they are critical to your proof of concept.

To continue with your FWD project from here, we recommend you consult the FWD documentation for further guidance. As noted earlier, the Methodology chapter of the FWD Conversion Handbook is a good next step.

If you get stuck, don't be discouraged; there are resources available to help you.

• Register for an account to join the FWD community.
• Check out the FWD Forums to post a question or search for a topic.
• If you believe you have found a defect in FWD, would like to request support for a particular feature, or have something to contribute to the project, please refer to the FWD development process wiki page for instructions on submissions.
• Contact Golden Code Development, the creators of the FWD project, for professional services, including adding features to FWD, assessment work, proofs of concept, full migrations, or anything in between.
• Follow FWD on social media to get news about the project as it becomes available.