I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.
The system isn't obsolete if people are still using it and it's supporting the business activities. Since it's still being used, the business can't just throw it away - it needs to be supported until the need for the system no longer exists. That could be a change in business objectives or a new system has been developed, tested, and deployed successfully to the end users.
Really, 5 years isn't that long. I've worked with code that was 10 years old before. If it's still serving the needs of the user, why throw it away? That's throwing away a lot of money spent to develop it. Until it becomes unfeasible to maintain due to increasing costs or the requirements change drastically, there's no business reason to throw it away.
Management now wants to extend the project for another year, and in the process nearly triple the user base.
If management says that this system is "on life support", why are they trying to deploy it further? It's common that maintenance activities continue on a legacy system until it's replaced, but if a system is in end-of-life, it's not typically deployed to more people. Extending maintenance is one thing, but adding users who rely on the system is a different situation all together.
To me, it sounds like it's not actually end of life, but rather in a maintenance phase and will continue to be there until the system no longer serves the needs of the users.
As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?
You need to continue to support the old system. Later, you mention that software is not your company's primary business. In such an environment, the job of software teams is to support the company's primary business. However, the software teams also need to keep the business objectives in mind.
In the mean time, capture your suggestions in a way that isn't overbearing. Point out other technologies or techniques that could be integrated with the system or used if/when a new system is created and their pros/cons. How you do this depends on the company, but considering some later points, perhaps establishing a wiki or other collaborative site would be useful.
In a non-software business, software is a cost and the software teams (especially the software project/program managers) should be working to minimize the cost of building and maintaining software systems as much as possible, while supporting the needs of the end users. Throwing away software that (as far as I can tell, from your post, anyway) meets the needs of the users goes against what's in the best interests of the software team.
*To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, no requirements documents. The development is very ad hoc.
To me, this is the problem. Not producing documentation, not developing to a specification, and a lack of consistency tends to increase the cost of developing software. Working toward fixing this would be my highest priority, and I would do that by working on things like a coding standard, version control, producing self-documenting code and design documents, defect tracking, and requirements specifications.
Best Answer
Who will be reading the documentation? What will the documentation be used for? These are the most important questions to answer. For example, documentation for maintenance developers would focus more on structure whereas documentation for developers integrating with the product would focus more on web services and database structure.
In general, do as much documentation as is required and no more. Many organizations require documentation because someone insisted it is best practice but the documentation ends up gathering dust.
Assuming that people will actually use the documentation, do not try to capture the code and database to the smallest level. Developers will look at the code for minutiae. Instead, focus on details that are not apparent in the code, for example:
Even if all this information is not available, start now. The developers that come after you will thank you.
Good automated unit tests or test cases can also be useful documentation, albeit hard to access for less technical people.
It also sounds like you need to make a cultural change to include documentation. Start small but, ideally, the project should not be "done" until it has at least a minimal level of documentation. This is probably the hardest step because the above are things you can control. This is something others must buy into. However, it can also be the most rewarding, particularly if the next project you do comes with good documentation.