Hi,

As we know, starting next year Salesforce will stop providing option to write/develop new s-controls in the org. This is part of the product roadmap where s-control becomes an obsolete technology moving forward.

Does Salesforce have a recommendation on the replacement options of existing s-controls that are working today? As s-controls nears EOL (end of life) stage, even older s-controls will have to be retired and converted into an alternate technology like Visualforce.

1) I wanted to check with peers in this forum, if you are aware of any recommended approaches to migrate or replace s-control code.

2) One of the pattern that has started emerging (at least this is what I notice with some of our customers where we have lot of non-UI s-controls doing batch kind of processing) - bulk of the processing within s-control, mostly dealing with SOQL & DML operations, has been moved to APEX class and exposed as a Web Service.

existing s-controls becomes lightweight and invokes APEX web service for main business logic.

In this case, since most of logic has already been shifted out of s-control we can easily get rid of such s-controls by using inline Javascript option and whatever little processing is being done in s-control (showing alerts to user etc), that can be accommodated in inline Java script and hence practically doing away with s-control.

So we can see below pattern, as a  phased approach for retiring s-control :

A) custom link on page --> invokes s-control --> API calls to server

B) custom link on page --> invokes trimmed down s-control --> calls APEX web service --> Database calls

C) custom link on page --> inline JavaScript code --> calls APEX web service --> database calls

Would like to invite comments on above approach (works with non-UI, batch process s-contols) from experienced s-controls developers to validate if solution (C) will work equally fine.  

Important --> Remember we continue to use/refer to "connection.js" & "apex.js" in option C (inline javascript) as well. Since this is part of AJAX toolkit, I believe retirement of s-controls from the scene isn't going to impact the way we work with AJAX toolkit in future.

3) For bulk data processing s-controls, we can't think of replacing it with Visualforce as APEX governor limits constraints starts applying. In s-controls, we had the flexibility to batch and process records so we can work around these governor limits. For that matter any client application on force.com API doesn't have restriction on governor limits.

So question is how do we handle such cases? What can be a possible retirement strategy? VF+FLEX mashup? 

Appreciate your comments, suggestions.

Thanks

Satgur