I actually wrote about this a couple years ago: https://www.cjsharp.com/blog/2018/09/28/architecting-multi-site-episerver-solutions/
We just started development for a client with multi-site, and each site is uniquely different (no sharing of content types, no consistent layout, etc), so we are doing the MVC Area method. Our architecture has a bit of an overhead in the form of a bunch of base classes and allowed types, but in the end, we hope the developer experience will be pleasant, since code for all the sites will be compartmentalized, and the editor experience will be pleasant because they can only create new page/block instance for the site they are working in.
As far as migrating blocks into areas... shouldn't be a problem as long as the GUID stays the same. You can add a GroupName to the ContentType to organize, and as I mentioned, you might want to use AllowedTypes to limit specific blocks to one area (maybe have base content type classes for each site and go from there).
It's a fun architecture conversation for sure. My team talked for a couple hours about the pros and cons of each method.
I have a project that is currently a single website in production, but is going to be migrating from a single website to a multi website instance. In regards to re-organizing the code base, do you have any pointers on what a proper architecture may look like?
I have a few ideas that may help:
Ideally both websites share a common block layer but have their own CSS/JS applied. I am really leaning toward introducing MVC Areas. If I do introduce areas, is there any risk in migrating existing blocks and page types into their own dedicated areas?
How do you tackle this problem?