Database Reduction Project

[akbryer]

We are in the process of reviewing all of our Lotus Notes databases/applications in order to determine which dbs/apps are under utilized or outdated, or both. The ultimate result will either be removal from production, or in some cases enhancement.<br>
<br>
We are beginning the process by making an Excel spreadsheet broken into chunks of accesses covering the 12 month period from January, 1999 through December, 1999.<br>
<br>
We will be contacting DB Admins/Owners and/or users to determine the type of usage, needs, and to see if there is a business case for not removing the db/app from production... <br>
<br>
I'd be interested in learning if others have undertaken such a project, and would be willing to share strategies, tips, trials and tribulations, results, etc.<br>
<br>
Thanks in advance. <p>Gary (akbryer)<br><a href=mailto:Gary_Bryer@Vanguard.com>Gary_Bryer@Vanguard.com</a><br><a href= > </a><br> <br>
<br>
Good deeds do not go unrewarded!

 

[rzen]

perhaps this is one of those areas when optimal solution depends on your company's Notes infrastructure, number of databases and overall requirements. couple of pointers, most of which are probably obvious, so apologies if i'm repeating your own thoughts.<br>
<br>
1) stay with notes databases. compile a quick database (discussion type), distribute it among your users (db admins) and collect information in an organized fashion. this will keep all comments in one place and will hopefully better retain the knowledge of app usage;<br>
<br>
2) start with database catalog (catalog.nsf). it should contain info about all databases in your company; probably import the list into the db mentioned above. make sure to assign &quot;db owner&quot; and &quot;db location&quot; to each databse;<br>
<br>
3) trust users, use organisational measures. meaning, more likely than not, your users know better which apps they need and which they dont. good idea though to force them to make a decision. for example, announce that apps need for which is not confirmed within a certain time frame will be retired.<br>
<br>
4) try to be personal. do not overwhelm your users. since the owners of the apps are known (see #2) send emails in db-specific manner. for example, &quot;Dear John Doe, your appliaction such and such [db link] may be retired within X number of weeks, please respond here [doclink] if there is a business need to keep it.<br>
<br>
5) try to do as much analysys as possible before hand. use &quot;User Activity&quot; to assess how recently the database was in use and by whom. presort databases as &quot;candidates to retire&quot; and &quot;candidates to stay&quot;.<br>
<br>
6) try to work with as few people as possible.<br>
<br>
this is no easy task, so try to take it slowly and back-up back-up back-up <br>
<br>
best of luck,<br>
rouslan<br>
<A HREF="

http://www.notesnet.com/"

TARGET="_new">

http://www.notesnet.com/</A>

 

[akbryer]

rouslan,<br>
<br>
Thanks for your input. Some of which I had thought of, which you have reinforced (which, to me, is as important as a new idea), a few points that I hadn't thought about, such as the creating a discussion db (although, I think I'd like to make a combo, mail-in, discussion and doc library).<br>
<br>
Thanks, again. I appreciate your time. <p>Gary (akbryer)<br><a href=mailto:Gary_Bryer@Vanguard.com>Gary_Bryer@Vanguard.com</a><br><a href= > </a><br> <br>
<br>
Good deeds do not go unrewarded!