Framework lock-in can be a serious issue, but it helps to look at the problem as one of portability. Portability is not an absolute attribute, but relative to your starting point and where you might possibly want to go. By analogy, then, software is portable only in so far as you have already ported it to other environments.
Most of the development of an application inside a framework tends to be glue code, the stuff that binds the components of your framework together. Configuration files may abstract a certain amount of the glue in some systems but a lot of the fine details have to be done in code.
On the other hand, business rules and processes can be abstracted from the application. The hard part of abstraction is when the rules are implemented directly by the framework; security, accessibility and process sequencing tend to be enforced by your framework and may be the hardest to see.
If you can separate the glue portion of your application from the business rule and business process and business data portion, then you will be able to make some portions of your solution portable.