I have a single umbraco code base that powers 10+ separate instances of Umbraco (10 different Websites)
Each website has multiple languages some have 2 others have up to 7.
We are looking to potentially change this set up and put all 10+ websites in to 1 instance of Umbraco.
Currently there are an average of 10 CMS users per website, so all together around 100 CMS users.
My question is these:
What are peoples experiences around managing a large Umbraco build with multiple multilingual sites and a high number of CMS users?
Are there any obvious pitfalls? (other than single point of failure)
Performance, are there any major performance issues I should be aware of before I start this challenge?
Currently the functionality around language has been implemented by creating multiple top level nodes for each one, there are other ways to do this, will this cause an issue if I try and put it all in one installation.
That is a multi faceted question - The answer can range from "Yeah, it's easy" to "Woah, it's complicated" and none of the answers are necessarily wrong. It really depends!
These 10+ sites are they very similar in functionality and visual appearance or do they each have their own unique design? And how about the backoffice setup? Are the document types they're using very much alike or do the sites have different options and document types? Are all the 10 sites for the same client or do you serve multiple clients with the same codebase with minor modifications to serve unique needs for them?
If the sites are basically build the same way and design wise have the same foundation, which are possible to easily theme by modifying a couple of colors and fonts then it should be fairly straight forward and easy to maintain.
So I guess my current response to your questions are the following
1: We currently have 1 client, which sell travels from 4 different brands in 5 different countries. The sites have different design but some of the components are shared and are easy to theme. But some places the design vary so much that we need to make separate views, JS and CSS files. It's no problem though - The main gripe I have with our current setup is that some of the document types contain fields that are only meant to be used by brand X and Y while Brand A and B should not use the fields, which means the editors for brand A and B are looking at some fields they can't use, which might confuse them.
2: Think about how you structure the document types if you're going to
serve some very different designs and the options that you make
available. You'll also need to consider your content structure and
how you setup the different sites and potential content repositories
depending on what you usual approach is. So many options these days!
:) - Also consider how the "Media" archive should be structured -
Will it make sense to have root folders for each site and perhaps a
shared folder? Make sure to consider how editors should have access
to content and media. Perhaps you need to have different groups
depending on how much they should be allowed to access etc.
3: Are you thinking about backend performance or frontend performance in this regard? Frontend wise you should carefully consider your setup so you don't necessarily use the same frontend modules on all of the sites if the differ design-wise
4: You should be able to use the same approach in a multi-site / multi-brand solution. For instance some of our current structure in the backoffice is setup like this
Brand node
Language
Homepage
Shared content repository
I hope all of the above makes sense and sorry if I mention things that you're already aware of but I'm trying to answer in as broad terms as possible in case some other people should come across this post and may not have the same initial level of experience :)
Jan - Thanks for taking you time to write such a long answer.
Yes, the sites look very similar, have very similar functionality so document types are relevant across all 10 sites.
Really and truly the only thing that is different from site to site is the Umbraco Database for each site.
The company are potentially looking at Umbraco Cloud, but one reservation they have is that they only have the option of one Azure region. - I'll get in touch with the cloud team to discuss in more detail.
Thanks again, you have pretty much confirmed what I was thinking.
Many things also depend on how the code is made in regards to performance and how Umbraco's API's are being called (If any calls are made etc. etc. etc.)
Yeah...Since it's the same codebase an mistake in a view, controller or whatever will obviously affect all of the sites if the "module" is activated on all of the sites for instance.
Database-wise I'm not sure though. But yes the downside of this approach is that you can have a lot of sites affected by one mistake. But on the other hand it's easy to fix for all of the sites ;-)
Managing Multiple Umbraco Instances.
Hi guys,
I have a single umbraco code base that powers 10+ separate instances of Umbraco (10 different Websites)
Each website has multiple languages some have 2 others have up to 7.
We are looking to potentially change this set up and put all 10+ websites in to 1 instance of Umbraco.
Currently there are an average of 10 CMS users per website, so all together around 100 CMS users.
My question is these:
What are peoples experiences around managing a large Umbraco build with multiple multilingual sites and a high number of CMS users?
Are there any obvious pitfalls? (other than single point of failure)
Performance, are there any major performance issues I should be aware of before I start this challenge?
Currently the functionality around language has been implemented by creating multiple top level nodes for each one, there are other ways to do this, will this cause an issue if I try and put it all in one installation.
Thanks Ayo
Hi Ayo
That is a multi faceted question - The answer can range from "Yeah, it's easy" to "Woah, it's complicated" and none of the answers are necessarily wrong. It really depends!
These 10+ sites are they very similar in functionality and visual appearance or do they each have their own unique design? And how about the backoffice setup? Are the document types they're using very much alike or do the sites have different options and document types? Are all the 10 sites for the same client or do you serve multiple clients with the same codebase with minor modifications to serve unique needs for them?
If the sites are basically build the same way and design wise have the same foundation, which are possible to easily theme by modifying a couple of colors and fonts then it should be fairly straight forward and easy to maintain.
So I guess my current response to your questions are the following
1: We currently have 1 client, which sell travels from 4 different brands in 5 different countries. The sites have different design but some of the components are shared and are easy to theme. But some places the design vary so much that we need to make separate views, JS and CSS files. It's no problem though - The main gripe I have with our current setup is that some of the document types contain fields that are only meant to be used by brand X and Y while Brand A and B should not use the fields, which means the editors for brand A and B are looking at some fields they can't use, which might confuse them.
2: Think about how you structure the document types if you're going to serve some very different designs and the options that you make available. You'll also need to consider your content structure and how you setup the different sites and potential content repositories depending on what you usual approach is. So many options these days! :) - Also consider how the "Media" archive should be structured - Will it make sense to have root folders for each site and perhaps a shared folder? Make sure to consider how editors should have access to content and media. Perhaps you need to have different groups depending on how much they should be allowed to access etc.
3: Are you thinking about backend performance or frontend performance in this regard? Frontend wise you should carefully consider your setup so you don't necessarily use the same frontend modules on all of the sites if the differ design-wise
4: You should be able to use the same approach in a multi-site / multi-brand solution. For instance some of our current structure in the backoffice is setup like this
I hope all of the above makes sense and sorry if I mention things that you're already aware of but I'm trying to answer in as broad terms as possible in case some other people should come across this post and may not have the same initial level of experience :)
/Jan
Jan - Thanks for taking you time to write such a long answer.
Yes, the sites look very similar, have very similar functionality so document types are relevant across all 10 sites.
Really and truly the only thing that is different from site to site is the Umbraco Database for each site.
The company are potentially looking at Umbraco Cloud, but one reservation they have is that they only have the option of one Azure region. - I'll get in touch with the cloud team to discuss in more detail.
Thanks again, you have pretty much confirmed what I was thinking.
Ayo
You're welcome - Happy you found it useful :)
Simon Dingley also have some relevant points in this thread https://our.umbraco.com/forum/using-umbraco-and-getting-started/92443-single-umbraco-installation-for-30plus-websites#comment-292185 and above his comment Søren Gregersens mentions they have a solution with 100 similar sites in it - So I don't think it should be an issue in your scenario but good idea to discuss it with the cloud team as well.
Many things also depend on how the code is made in regards to performance and how Umbraco's API's are being called (If any calls are made etc. etc. etc.)
Have a nice evening!
/Jan
Argh, the indentation of the list is a bit messed up - Homepage and Shared content repository should be indented further but seems like it's stripped.
But Brand node is level 1, language is level 2 and homepage and shared content repo is level 3.
/Jan
The only other question I have at this stage is, what can we do if anything.......
To set things up to be as robust as possible, what I mean is, a problem on one site might mean all of the sites go down. -
Yeah...Since it's the same codebase an mistake in a view, controller or whatever will obviously affect all of the sites if the "module" is activated on all of the sites for instance.
Database-wise I'm not sure though. But yes the downside of this approach is that you can have a lot of sites affected by one mistake. But on the other hand it's easy to fix for all of the sites ;-)
/Jan
is working on a reply...