In my current project some components are standalone( neither a child of foundation nor wcm core component's) and some are child of foundation component so requirement is to migrate all those foundation components to wcm core components. After reading some adobe articles I reached on the conclusion that:
There are two ways to migrate foundation to core component-
1. If functionality matches then use resourceSuperType to refer the respective core component and write interface based sling model if customised.
2. If functionality doesn't matches, at least write interface based sling model.
Please confirm whether my understanding is correct or not.
If not, please suggest an approach to accomplish the requirement.
However, one thing to be aware of is that Core Components come with a number of methods to modify them without needing to write new code. These non-code customizations are called policies, you can read more about them here. If you want an example:
Before Core Components, the Image component let authors upload images from their PC (bad idea). The Core Component Image has a policy that lets you disable this feature (much safer). You can read about that here.
In order to use policies though, you'll have to migrate from Static Templates to Editable Templates (which I highly recommend). These let you build and design your templates in an editor rather than in code, and offer many more features than Static Templates.
Also, one semantic detail: a component that uses a Sling Model is not, by definition, a "core component". The term "core component" refers specifically to the components offered by AEM Core Components.
Can you please explain why you would want to migrate all existing components from foundation components to WCM Core components? Why was this decided? Taking a closer look at the content WCM Core Content Components:
WCM Core Components are implemented with Sling Models.
WCM Core Components all implement the Jackson Exporter to be exported in a serialized JSON object; Jackson Exporter enabled components are useful in combination with editable templates (content services).
What's more interesting is the WCM Core Page Component:
Supports editable templates.
Supports out of the box content services of .model.json (on the page) with exposes a serialised JSON object from the cq:Page object; when using a combination of the editable templates and the layout container component.
Here's what I would do. The first thing I would do is to convert the base page to extend the WCM Core Page Component. The WCM Core Page Component is important as there are new behaviours included in the supporting scripts of the Sightly HTL templates that support new features such as editable templates; used for templates or experience fragments (read more here). After creating a new base page component and all other supporting page components, you would need to either think about using editable templates or continue on using static templates. Whatever choice you decide, you would next need to apply a migration script; to update all existing content nodes to point to the new static or editable templates. During script migration, ensure that you are progressively upgrading pages to test as you go.