@Roland,

In PowerBuilder 10.5 is was already possible to show files and subdirectories in the systemtree and also to add them to (and use) the source control by using a webtarget target type.

Food for real deep thought ;-)

IMO, the migrator's main benefit was to allow PB logic to be used in/as/with a web api.  The drawback was that you then had to maintain it in c#.  If you have a lot of c# developers and few PB developers, that is probably fine.  

We use c# to create minimal apis and handle the security for them, and then call/run PB nvo processes from the C# webapp.  I recall that Chris P. has done something similar for a very long time.  The main issue with this method is scalability, which can be handled by auto-scaling out to multiple machines.  Since PB isn't thread safe you have to run each call in its own process which one of the scalability issues.   This allows us to maintain the logic in PB and really have the best of all worlds.  We do this for relatively long running or heavy processes that are run occasionally.

Will the SCC API be available with the 'no PBL' mode?

I suggest adding some way to source control non-PB files such as image files or PBR files directly from the IDE.

Yes, we are absolutely committed to cloud architecture.  We have already made and continue making significant investments in consuming Web APIs, developing Web APIs with DataWindow technology, and PowerServer cloud deployment.  The discontinuation of PowerScript Migrator should not be misinterpreted that Appeon is not committed to the cloud roadmap focus that we laid out years ago and have been executing against consistently ever since.

Now as far as why we discontinued PowerScript Migrator, it basically boils down to what Miguel and Arturo said.  PowerScript Migrator is a simple syntax translator, and we never marketed it as some magical solution.  Unfortunately, we misjudged the market... most customers either want something that eliminates majority of the conversion effort or they won't use it at all. 

As a general rule, we do not discontinue a feature unless there is something better to replace it, the feature has little to no demand, the feature doesn't align with our roadmap, and/or the feature is security/liability risk.  Sometimes a feature we discontinue might be combination of the reasons I mentioned.  For the case of PowerScript Migrator, it had little demand and was liability in the sense many customers feeling misled due to mismatch in expectations.

I've only tried it out once, but I think that the code generated by the migrator wasn't that great.

Thanks!