I am going through a similar process to you with some exceptions. I too wrote our systems in 2.3B. In those days Novell was the only realistic nework system and, when Novell made a free copy of Btrieve available with its server product, I converted my data to Btrieve and changed to DFB2.21 (Dataflex for Btrieve). I still have one small business system running with that product. My other two businesses are running on DF3.1b which, like 3.2 supports drivers including Btrieve (now Pervasive SQL) MSSQL and ODBC.

On the way through I needed a web-site so I had a developer write one in PHP and Angular.js while I provided all the data handling via web services written in Df 17.1 (now DF18.2). I did use a lot of my DF3.1d code in those web-services. One of the things I have been able to do is to utilize some of those web-services from my DF31d code. You could even use them for transactions if you needed to. In my case, I use them for printing Orders & Invoices with Logos, images etc. It is also very good for sending emails. Basically, it will work for any Business process which doesn't require user input. Since I do this using "Runprogram Wait" it would work in DF2.2b.

I can see you using the above approach for several reasons:
1. You can learn about using Data Dictionaries and programming in DF 20 while writing the web-services.
2. You can still use the DF2.3B Dataflex tables so both the DF2.3B programs and DF20 Web Services can work on the same data. Nevertheless, I would make a copy of the data to use while developing the Web Services.
3. You may not need all the additional applications like Excel, Word and pdf.
4. You can still continue to use the existing system and gradually enhance it using the web-services.

When you feel confident in using DF20, you could develop a complete replacement system in DF20. I would recommend using a Mobile Webapp which, as others have said, is much more like the DF2.3B approach. At this point, you should be able to use much of the code you have developed for the web-services (but not your 2.3B programs).

To start the process, you should write a data conversion program which transfers data from your embedded database to MS SQL, changing the structure on the way, if necessary. In this way, you will be able to cut over to a thoroughly tested system using an SQL database without having any interruptions to your business.

I can speak with some authority on this since last year I contracted a well known DF developer to convert my whole system to DF20. The data structures are being tidied up and changed considerably but the conversion application handles all that while the business continues to run the existing system undisturbed.

One thing to consider is relationships. In the Console Mode days the recommended way to establish relationships was via Recnum. That fell out of favor some years later, partly because of the ability to reuse deleted Recnums. Now, although you can retain recnums during conversion to SQL when they will become auto-increment fields, they are not supported when creating Relationships in the Studio. Instead, you are advised to use another field (Code, say). Under these circumstances, you would be better to convert to Standard tables and make the Code field auto-increment. However, that can be handled by the conversion program which would move Recnum values into the Code field so there would be no need to make any changes to your existing system.

I have found that one of the biggest jobs for me is to identify and record all the business rules which are scattered throughout the DF31d programs. This has meant, in some cases, examining programs which I wrote over 15 years ago. I have found a number of inconsistencies and have identified a lot of improvements which I would like made. This should probably be your first task.

I mentioned above being able to access web-services from DF2.3B. Since all our users run on a terminal server I was able to install php on that server. If you run from local workstations, you would need to install php on each one. Then I created scripts like CallwebService2.php below:
     $url = "http://localhost/IFAS/Documents.wso/CreateDocument/JSON?iRefNo=" . $argv[1] . "&sReportType=" . $argv[2] . "&iUserCode=" . $argv[3] . "&EmailCtrl=" . $argv[4] ;
     $result = file_get_contents ( $url );
     // Un-comment the following statement for testing.  Note that, like DF, php uses // for comments    
     //echo $result;
This is accessed from a CM application as follows:
  runprogram wait php.exe  "W:\Scripts\CallWebService2.php " ( (string(Invoice.Number))+" I "+(string(Recipien.Contact_Code))+" 3" )
This emails the specified invoice to the email address of the Recipien.Contact_Code. The final argument (3) determines how the email address is found by the web-service.

I hope this is of some help.