1. James Hsu
  2. PowerBuilder
  3. Sunday, 26 July 2020 00:55 AM UTC

Hi, our organization is currently using a rich client desktop application developed with PowerBuilder 11.5.  We would like to migrate our application to the currently available PowerBuilder 2017 or 2019.  We were wondering if anyone had experiences migrating from a much older version to the currently available versions, and if you can share your general experience, recommendations, or useful guides for the migration.  We've looked at a few APPEON documentation for migration but they are mostly very brief and general at best, unless there are guides. 

We may also look at hiring PowerBuilder consultants depending on the result of product and upgradability assessment.  If anyone has any experience hiring, or are a PowerBuilder consultant yourselves, what is the current general market hourly rate specifically for this type of migration?  Quick look at ziprecruiter or Glassdoor shows a pretty big range and not very helpful for determining of pay for skills required. Any assistance you can provide is greatly appreciated.  

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Sunday, 26 July 2020 05:31 AM UTC
  2. PowerBuilder
  3. # 1

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

Comment
  1. Peter Andrews
  2. Monday, 26 July 2021 21:55 PM UTC
Thank you all
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Sunday, 26 July 2020 12:22 PM UTC
  2. PowerBuilder
  3. # 2

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

 

 

 

Comment
There are no comments made yet.
Andrew Barnes Accepted Answer Pending Moderation
  1. Monday, 27 July 2020 17:05 PM UTC
  2. PowerBuilder
  3. # 3

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. 

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Monday, 27 July 2020 20:43 PM UTC
  2. PowerBuilder
  3. # 4

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

Comment
There are no comments made yet.
Nasir Ahmad Accepted Answer Pending Moderation
  1. Tuesday, 28 July 2020 14:54 PM UTC
  2. PowerBuilder
  3. # 5

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

Comment
There are no comments made yet.
Stan Zihlman Accepted Answer Pending Moderation
  1. Wednesday, 29 July 2020 13:50 PM UTC
  2. PowerBuilder
  3. # 6

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.

Comment
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Tuesday, 18 August 2020 13:14 PM UTC
  2. PowerBuilder
  3. # 7

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.

 

Comment
There are no comments made yet.
Kevin Ridley Accepted Answer Pending Moderation
  1. Tuesday, 18 August 2020 15:55 PM UTC
  2. PowerBuilder
  3. # 8

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

Comment
There are no comments made yet.
paulo gomes Accepted Answer Pending Moderation
  1. Saturday, 22 August 2020 20:45 PM UTC
  2. PowerBuilder
  3. # 9

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. 

Comment
There are no comments made yet.
David Peace (Powersoft) Accepted Answer Pending Moderation
  1. Thursday, 27 August 2020 13:57 PM UTC
  2. PowerBuilder
  3. # 10

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

Comment
There are no comments made yet.
Jeff Nesler Accepted Answer Pending Moderation
  1. Thursday, 8 October 2020 15:57 PM UTC
  2. PowerBuilder
  3. # 11

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(). 

 

 

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 8 October 2020 16:50 PM UTC
Hi Jeff ... thank you so much for the feedback and the fix that you implemented to solve the issue!
  1. Helpful
There are no comments made yet.
Vijay Gopalakrishnan Accepted Answer Pending Moderation
  1. Tuesday, 20 October 2020 01:12 AM UTC
  2. PowerBuilder
  3. # 12

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. 

Comment
  1. Miguel Leeuwe
  2. Tuesday, 20 October 2020 01:22 AM UTC
Great! Thanks for sharing.
  1. Helpful
There are no comments made yet.
JIJO THOMAS Accepted Answer Pending Moderation
  1. Wednesday, 18 November 2020 19:24 PM UTC
  2. PowerBuilder
  3. # 13

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

Comment
  1. Armeen Mazda @Appeon
  2. Wednesday, 18 November 2020 19:43 PM UTC
Hi Jijo, Migrating from a PowerBuilder version that is so EXTREMELY OLD is not going to be as easy as what most Appeon customers experience... so much has happened over 20 years! I really recommend your company get some consulting help. Check out this presentation from Elevate that was migration from PB 3.0 by one of our consulting partners: https://youtu.be/46nd0hziXYo
  1. Helpful
  1. Sivaprakash BKR
  2. Tuesday, 27 July 2021 04:56 AM UTC
Migrating PB 6.5 to PB 10.5 itself was a big headache then that we abandoned the migration and did a full development in PB 10.5.
  1. Helpful
There are no comments made yet.
Matt Balent Accepted Answer Pending Moderation
  1. Tuesday, 27 July 2021 11:56 AM UTC
  2. PowerBuilder
  3. # 14

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.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.