There are very good reasons why an institution would want to maintain the work of one of its affiliated scholars after said person has left the institution. The least compelling reason from most scholars' points of view is the increasing regularity with which institutions are reserving the rights to research so that they can monetize it should it ever appear to become valuable. A more important reason is that institutions are increasingly realizing that collecting and preserving the intellectual output of their faculty is important to future of scholarly research. And finally, most major granting institutions (both private and public) will demand that a solid, long-term maintenance plan be in place prior to funding. Given all of the above, the question, “How do you maintain digital projects in the long term?” is a question with which anyone hoping to get a funded digital initiative off the ground will necessarily have to grapple.
In trying to answer this question you should start to think about the difference between the data created by the project and the project's user interface. Keeping a site live and publicly accessible to everyone over the internet (which means keeping the UI maintained, updated, and serviceable over time) is one kind of preservation; but storing the data itself in an easily readable format and preserving it just as you would any other library collected object, is also a form a preservation—one that I would argue is, if not more valuable at least more realistic. This distinction is, of course, difficult to draw for a handful of resources where, as they say, the medium (in this case, the UI) is the message. But these represent an overwhelming minority of the scholarly works on the web.*
Expecting an institution to keep a digital project alive and universally reachable for eternity is, as Patrick Murray-John suggest above, an unreasonable proposition—the historical equivalent to demanding that every library keep every copy of every book ever printed. It's impractical and also stifles experimentation and creativity as it drives everyone to deliver their content in one of a small number of community supported platforms which may or may not be optimal for the content being created. (It often is, but not always.)
Shift the preservation focus away from the front end to the back end and convince your library to agree to archive a collection of well-structured, XML, flat-file representations of the data created by the resource (and by archive I mean not only store, but also enter it into their catalogue and OCLC so that it can be found). By doing this, you insure that the data itself is accessible to any motivated scholar to make use of as appropriate in the event that the sites primary user interface has outlived its useful life.
-----
* for a good overview of the full complexity of the curation process of born-digital objects, see, for example, Matt Kirschenbaum's white paper, "Approaches to Managing and Collecting Born-Digital Literary Materials for Scholarly Use" at https://securegrants.neh.gov/PublicQuery/main.aspx?f=1&gn=HD-50346-08
