Seeking advice on untangling the hornet's nest that is my business's website
I'm in a decade-long predicament related to the management of a somewhat complex website for my publishing business, and I'd appreciate your advice. For context:
- I joined the company as an original founder about 15 years ago. My initial roles mostly dealt with accounting, finance, sales, account management, etc. -- really, anything and everything I could help out with. I offered to take ownership of our website since I had a fair amount of web design and programming experience.
- The original version of our website was a patchwork of PHP scripts from back in the days before Composer. I was inexperienced and didn't know anything about frameworks, etc. so I just started adding code.
- Over the years, I built homebrew versions of user authentication, a backend (CMS, CRM, etc.), and our front-facing website (full-stack, from cloud hosting to CSS and everything in between). As the story goes, it became a spaghetti code mess that was only maintainable by me.
- Realizing that I'd created a mess, my next long-term project was to slowly start transitioning the entire backend over to the Symfony framework, including many/most of the homebuilt components such as auth. This probably took 5 years in earnest. This way, I could at least begin to have conversations about getting outside help.
- The other founder passed away unexpectedly, and I've found myself not having enough time to dedicate to the website. I can work on it here and there and patch it up when things break, but my fear is that we're going to become stale.
- I've had several conversations with individuals and web development companies in various capacities over the years. These conversations ranged from "sure, I can help out with front-end stuff" to "we would like to rebuild your website from scratch using (insert popular CMS) and then manage it for the low cost of (insert high cost)".
Right now, all of the coding goes through me because it's the cheapest option (plus all of the context above). I'd like to explore delegating or outsourcing it again, but I don't know where the happy medium is as far as what needs to stay in-house.
Just to give an idea of the complexity, as it goes well beyond what you would think a publisher needs, here are some of the features:
- User auth/database with tens of thousands of users
- Single sign-on that connects those users to several other platforms seamlessly
- Content authoring
- Several "microsite" type pages on the front end that require their own CSS/JS needs
- Some unique features that were built because we couldn't find suitable alternatives, such as a webinar player that automatically generates certificates and stores them for the user, watermarked PDF downloads to include user information (i.e. to prevent piracy), etc.
- CSS from the Bootstrap 3 era that has been modified and bolted onto over the years
- Jquery stuff from way back in the day
- and on, and on, and on
To do things right, I would think that I need a server admin, a Symfony/PHP expert, and a front-end expert. But we're talking about what - hundreds of thousands of dollars per year? We can't afford that.
In my mind, an ideal situation looks like this:
- I am still able to see, modify, and keep control of our codebase (Git)
- Hosting is managed. This is where my second biggest* fear lies, in that I know enough server admin to be dangerous, but I lose sleep knowing that an intrusion is inevitable and there are smarter people than me that can help prevent one.
- I can assign out projects (e.g. we want to upgrade to PHP ## and Symfony ##, we want to redesign a page/template/etc., we want to implement SAML and connect it to another platform, etc.)
*My biggest fear is that, since I hold the keys to everything related to this website, if I am unavailable (or get hit by a bus) then I leave the business in a REALLY bad place.
Can anyone offer any advice on navigating this hornet's nest?
Here's some quick advise. Without analyzing more specific details, I need to keep it sorta high level and generic.
Highest priority is the hosting. Sounds like you want as much of a hands off solution as possible. You can get a managed server with your tech stack. PHP and a database? Given the age of other things, MySQL? Go to LiquidWeb and pick up a managed VPS or Dedicated (depending on your capacity needs). They will 100% manage the server. You will have a control panel you can easily do the things you need to do.
Get all your existing code in Git. Just do it. You can clean things up later.
Create a roadmap for code optimization, cleanup, modernization, and enhancements. Break this roadmap down into actionable tasks. Then you can take on these tasks, or contract them out. The better defined and broken down the tasks are the easier they are to knock out.
#2 especially!
Sorry, I should have mentioned that everything is in Git and the codebase is mostly configured for self-hosting in dev environments (e.g. separate .env to keep out secrets, database fixtures, etc.)
Awesome.
There is some wisdom in that. It is often quicker and cheaper to rebuild a complex application from scratch than to refactor ( after spending time to learn the code, making sure new stuff doesn't break old stuff, etc ) the complex code.
Since you know the site and the business you could generate a list of requirements for a replacement site ( maybe leaving the database as is ). You can outsource using that list to generate a design for a project or do it yourself. Once you have that design, you can build the new site piece by piece as you have time, keeping the old site running. You could even hire help to work on it as much/little as you like ( with the provision that there are code reviews where you give the final say ). As part of the design come up with standards as to how the code is to be commented. A large explanatory block at the top of each file. 1-2 lines per function, and more as needed in the code. Perhaps you can number elements of the design and insist that those number be used in each file that implements it. If you can no longer maintain the new site, whoever does it will have a list of requirements, a design with numbered parts, commented code with reference numbers as to how it implements the design.
Setting aside the monetary cost for a moment, the technical approach could be something like this: An experienced senior developer should do/lead this, so as to keep quality high and technical debt low, etc. The dev team can look for ways to parcel off portions of the whole system such that the rewrite can be done gradually, and live (i.e. not wait for the entire migration to be implemented before releasing it live). This will be tricky, but the idea is to have both old and new code and system parts running live, and cooperating with each other. The first main hurdle will be sharing authentication with both, so that being logged into the old system means also being logged in on the new system.
Then, you can migrate from old to new, bit by bit, with reduced risk, and over a reasonable time period (months, maybe 1-2 years), without (much) downtime, without temporarily losing features, without disrupting your users' experience too much. The idea is to actually retire parts of the old system/code as the new one is capable of providing the features. Wherever possible, you'll want to try to make the user experience seamless, so that end users can't even tell that new code is doing what the old code was doing. With some things this will be possible, with others, maybe not.
The actual details of this kind of migration will depend on the actual system and code themselves, so I can't comment on that, but an experienced developer should be able to draft a plan (or three) after having sat down with you (and whoever else has experience with the in-house code), and having reviewed the codebase and DB. Off the top of my head, some techniques that could be employed: database dual writing, API endpoint versioning, frontend libraries and frameworks that play well with others (and don't require exclusivity in the codebase), multiple API domains, wrapper/shims for API calls so that each call can be migrated from old to new independently of the calling code.
Now, back to the topic of money. You might be able to get by hiring just one single person who has a multi-faceted skill set. You'll get it all done faster by adding a few more people, though (up to a point of diminishing returns, of course). These kinds of decisions will depend on what kind of timelines or deadlines you want to set and meet, and your budget.
Hope this helps, and I wish you success.