Hello ojs_univie,
This is a question that I have been thinking about for a long time and to which I would like to arrive at a universal answer… but I think that in the end it all depends on the context in which you are, the resources and your team preferences.
I will try to answer your questions quickly, but feel free to ask further is something is not clear enough:
1. Has anyone in the community done something like this before? What has been your experience?
Yes. There are several institutions that use the “single-tenant” (understood as “one ojs for each journal”) model.
I am writing to you from the UAB, where we have more than 50 journals with independent ojs since… more than 10 years ago.
We like this model because it corrects the problems you mention (and some others), but let me notice it is not without its drawbacks.
If I remember well, @ctgraham (form the University of Pittsburgh) moved to single recently, so I’m sure he can contribute from his experience.
Comment that there are also organizations that have opted for a mixed strategy (some journals in single and others in multi). Probably PKP services is the most relevant example here.
2. Are there any reasons that make this idea unfeasible?
No. The multi-tenant to single-tenant migration process that you describe is the one that most of us have followed because it allows us to preserve the history of the magazine. The structure of OJS is clear and that allows each journal to be easily isolated (files and database). I do not recommend any other mechanism, unless you don’t mind losing a lot of information about the life of the articles.
While that path (multi 2 single) is relatively easy to walk, it is important to note that the reverse path (single 2 multi) is NOT.
In other words, if you change to a single-tenant model it will be a difficult change to reverse.
3. Are there better strategies for improving stability that we are not seeing?
I can’t tell you in the multi-tenant context but in single, I think one way to improve stability is dockerizing your ojs.
That improves testing (container’s portability let you test migrations with an exact copy of your production service), its resilience (if a container falls, you restart it and mess up)
and it even offers some improvement in terms of security (the cages isolate the processes).
4. Any guidance would be appreciated.
Make a decision (single vs multi) and we will tell you here the steps to take.
But before this, although apparently the post is unrelated, I think this thread can be useful for you… specifically this table:
It’s quite obvious that I’m very convinced of the “single-tenant” model, so I think you also need to hear arguments of the ones that are happy with the ones that maintain large installations under a multi-tenant model (@ajnyga any comments about this?)
Take care,
m.