PowerBuilder 11.5 to 2019 should be straightforward and easy.  

We recommend you use the resources at the bottom of this page:  https://www.appeon.com/products/power-builder/migrating-to-pb.html

If you still really are stuck, we recommend you engage one of our consulting partners: https://www.appeon.com/consultants/consulting-partners

what Armeen said.  It will be simple to migrate it. 

Migrating from PB11.5 to PB2017 or PB2109 should be trivial.  A couple years ago we migrated out extensive application inventory of rich client PB applications from PB12.5 to PB2017, and the process was basically to open the application in PB2017 and click yes on the prompt to migrate the application.

In my shop, the biggest issue ever on migration was going from PB9 to PB12.5 because of the switch from ANSI strings to Unicode strings which played havoc with our use of distributed objects, however 11.5 is already Unicode so you will have no issues there.

The next biggest issue ever on migration, again going from PB9 to PB12.5 was due to Sybase having changed the appearance of all the built-in toolbar icons.  This was a pure application appearance issue and did not affect actual functionality, and we got around it by capturing all the old icons as .BMP and compiling them into a .PBD.  However, I do not believe that this would affect you because as near as I could figure looking at old release notes, the toolbar icons were changed in either 10.5 or 11.

As for hiring consultants, my suggestions would be to first simply try it yourself.  If for some reason, you do have an unusual situation that occurred either during the actual migration or testing of the migrated code, post your question on the Q&A forum and likely as not somebody would have an answer. 

Greetings, James -

I agree with others that the code migration should go very smoothly. There are some post-migration concerns you should be aware of, however.

Native PDF generation. If you have been using GhostScript for PDF generation, you can continue to do so, if needed. Test, test, test the NativePDF functionality. We had to make some changes in our app's framework to utilize the settings we decided worked the best for our customers, because we did not want to manually touch/change 1,000+ DataWindows. Things like: Default paper size is A4 and non-bitmap graphics get converted (poorly) to Bitmaps. Although features and usability continue to improve in every release, there are still some things that GhostScript does better or does that NativePDF cannot do at all.

Packaging. If you are used to creating your own installation package for your app(s), note there are several new run-time DLL's and related-support files that may need to be included with your application. I suggest you utilize the run-time packager utility that is included in the product.

MAPI. SAP revised MAPI support in 12.5/12.6(?) to use extended MAPI and it is NOT the same. If your app uses the PB MailSession and related objects, you need to test, test, test, and then test some more. In our case, we had to refactor to utilize an alternative solution.

Platform requirements. Please look up and take note of the operating system platforms that are and are not supported, as this has changed since PB 11.5.

Good luck!

Regards, John

I have migrated around 6 applications to PB2017 from PB12.5, my observations:

1. The migration process is straight but be sure to take backups. 

2. Major issue I had faced was related to PDF generation. There were legal documents in PDF formats that were not printing as desired using PB2017 R1 native PDF. Since then native PDF has improved a lot and I hope you will not have those issues. 

3. If you are using Richtext datawindow then it needs to be tested as I had a few issues with it. 

4. Application deployment and testing was most lengthy process as the Dlls were updated. We had to verify the third party dlls are working fine and applications are stable in production environments. There were few third party dlls and applications we had to upgrade for compatibility. 

These points are for 32 bit applications which is the default one. Please note that 64 bit exe is all together a different topic and not discussed here. If you need any help or need a consultant feel free to contact me via LinkedIn https://www.linkedin.com/in/nasir398 . 

All of the earlier posts were spot on.

I have just migrated a V11.5 PFC application to V2019.

This was the latest of many migrations I have done over the years.

Because the was an enterprise PFC layer, the legacy PFC objects were not upgraded to the V2017 versions. 

So upgrade of PFC is optional or you can upgrade later to leverage V2017 features.

The migration was smooth and running in a day.

The suggested next step is source control.

If you use source code control (real SCC, not native) , then you can BUILD in a new version of PB (2017/2019 +) from your current version without converting.     If you are on PB 9 or prior and use external dlls, then you will probably have some unicode issues, but since you are on 11.5 this will work.  This way you can test the PB version build without having to fully commit to the upgrade by converting your source.   (You may have some issues with PFC, so keep that in mind)

What you need to do is write a set of build scripts using ORCA script and/or PowerGen.   Your scripts will delete your build pbls, then recreate them as empty pbls.  Then it will pull down your source code from your SCC and then load them into the build pbls (this does the conversion, but it is not your main set of pbls).   Then have it do the build.    IMO, this is the best way to do any build.  Once you have the build script, you can easily change it to do a build in a newer version of PowerBuilder.   

We follow this practice for our daily builds of 7 applications. Our current production versions uses PB2017R3 and we are also doing daily builds with PB2019R2.  The downside of course is that you can't use any new features in your production builds until you have committed to doing the conversion.    you CAN try some of the new features out by editing your build code, and you can test the build itself out.

I've done about 10 migrations so far. Most everything is straightforward. Best bet is to make backups of your current prod code, then let the migrator do it's thing. If you're going from a PB10+ environment it should be fairly smooth. The biggest effort is going to be testing. Probably the biggest difference will be source code management, using GIT or Subversion if you're not experienced with either. Others below have done a great job pointing out the few challenges, like PDF generation and 3rd party DLLs. PFC should be fairly easy as well, even if you have a corporate layer, if it was done as recommended with a PFD layer between the PFC and PFE. If you need any help, this forum is a great resource, and the corporate partners are awesome.

Kevin

Hi All,

We have migrated our PB Client/Server and Web applications from the previous Sybase PB versions 10, 11, 11.5, 12.0 and 12.5 to Appeon versions PB 2017 R2, PB 2017 R3 and PB 2019 and PB 2019 R2 with no issues whatsoever. 

Hi

We have carried out many migrations, we are one of the consultants Armeen reffered to. It should be straight forward except for PDF saveas, Mapi and richtext control.

Everything other people have already said so I have little more to add. Let us know how you get on.

Regards David

We upgraded 13 applications in 12.5 up to 2019 R2 with almost no issues related to the upgrade itself.  These apps interact with 3rd party controls and COM objects registered on Windows servers, and older SOAP and WCF web services, no issues with any of those.  We also moved from TFS to Bitbucket for source control, so biggest amount of time was spent dealing with the way PB structures the app and works with Git based source control systems.

The only code-based problem we found was dealing with datawindows that did retrieval using QueryMode.  Our 12.5 code didn't have explicit AcceptText() calls to accept the user's inputs in those situations, but it still worked.   After upgrade we noticed we did need to add those calls to AcceptText(). 

We migrated our app from PowerBuilder 11.5 to Appeon PowerBuilder 2019 R2 Version, we just implemented two weeks back, no issues everything is perfect and no issues at all. It is worth to move to 2019 R2 version. 

Hi All, Great to see the responses

I have PowerBuilder application which is currently running in PB 6.5. i have to migrate to PB 12.5 or PB 17 or PB 19. 

i did the Migration from PB 6.5 to PB 12.5 , i could see lot of declaration issues and function call errors after the regeneration.

Please help me if any one having PB 6.5 software.

i want to see the code in Pb 6.5 and i will rewrite the missing parts in Pb 12.5 , but unfortunately i am not having PB 6.5. having trouble for understanding login what they did in PB 6.5

Thanks in advance

I've migrated a variety  of PB applications over the years and agree with all of the previous comments regarding the process.  What I have found to be more problematic and time consuming is upgrading / migrating the underlying database (which you did not mention in your original question).  I did a presentation at the 2019 Elevate conference on this very topic and would be happy to discus if you have questions.