Take a look at how easy/convenient it is to make "old" information available elsewhere.

It seems to me that old configuration information is kept around in the file partly for version control information and partly because it might come in useful later.

In the case of version control, maybe, maybe you can move that part to a version control system like git or Mercurial. This will require support from all users, so that they also know where to look at older versions of the file. Maybe you can put the link to the repository viewer URLs at the top of the configuration file.

In the case of documenting history and/or old/other usages, it is much harder to move this to a different location, as people will likely differ on the terms to search for. In some situations I got buy-in from users using TiddlyWiki for documentation. In other situations, a long (long!) Word document where old topics get moved to the "done" section and current topics stay near the top of the document.

A third approach could be to create your own viewer(s)/editors for the document that hide commented-out lines or that reformat the "current" file with additional comments and maybe can link to relevant documentation etc. - but that introduces yet another tool to the set of tools that the users already have, and will need maintenance.

You are already talking to the actual users of the process, and while the process might be hated by everybody, it seems to already have worked for 40 years. Your replacement of the change process to these file(s) will have to take into account that there are some parts of the existing process that actually work and the new process ideally doesn't break the things that already work while improving the things that are currently preceived as risks or hard.

Consolidating the different files screams for something like version control and maybe a centralized process of changing the configuration file actually used in production. The daily backups are fairly close to version control already and people are likely also familiar with the process of retrieving a good version from the backup. Implementing a centralized process of updating the Master configuration will create a bottleneck there because if the person(s) doing that change are unavailable, no such change should happen. On the other hand, this will create a ground truth and eliminate the different versions of configuration files that people keep around for that one time they had to change that obscure thing.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.