We know that there is a way to refactor and rename a class which is under development. However, if there is a class which is already deployed to production but needs renaming would it be possible and if so what would be the best way to do it.
Normally, I would avoid doing it once it hits prod. Instead, I would rename it in app studio (updating the display label) but leave the class name alone. If we are trying to get it cleaner, then I would ask:
Are you persisting instances of the class?
Are you using the blob to persist instances of this data class?
Is the class used as an embedded page in another class that is persisted? (Work class or data class)
If there is no persistence to have to worry about, this is less of an issue. But frequently it is in play. The refactor wizard will clean up your data for you, but you normally only run that in dev. In prod, we would normally handle the update as a data conversion.
If I had to make the change (and persistence is in play) I would typically create a new class and property and migrate data. The historical cases will have embedded pages defined using the old class name and now you are wanting to rename the pxObjClass for the embedded data, but you really can’t do that because the pxObjClass on the embedded page has to match the currently defined class definition.
You might be able to get away with writing an activity that does a page-change class on your embedded property. Prior to writing the activity, you would have to withdraw the property, merge, recreate the property with the new definition. The in-flight cases/instances probably would start throwing errors the moment you access a page property with the wrong pxObjClass. So, you would likely need to add a new property, copy the data to that property, switch to an version of the app with a modified property definition and then copy the data back (and remove the copy property). Then you could withdraw the temporary property.
So, it gets pretty messy if you do it. Much easier to relabel the class name.
Just for completeness, and I am not recommending you do this, if you can kick your users off the prod system, you could unlock all the rulesets and run the refactor wizard in prod. You would want to do a database back-up prior because you would need to revert your changes if this goes bad. The risk with historical cases is that you may have to do more than just change the embedded page to bring the instance up to the current standard. You could potentially experience errors that prevent the routine from completing and then have a worse mess to clean up - triggering a database restore because you don’t want to clean that up in prod directly.