I have a couple of Drupal 6 sites using the Webfm module (https://drupal.org/project/webfm). This module was never migrated to Drupal 7 because in this last version of Drupal the file API changed completely, and the module would have to have been rewritten completely, and nobody did it.
My solution was to substitute the webfm module by the "Elfinder" file manager and corresponding Drupal module (https://drupal.org/project/elfinder). This does not substitute all the document manager features of webfm, it is just a file manager and has no database management of the documents, but on the other hand it is really good as an editor. So maybe I will complement it in the future with some "knowledge base" module to search and put metatags to my documents.
First of course you have to migrate your Drupal 6 site to Drupal 7. Enable all the modules in Drupal 7, you will not be able to enable webfm because there is no Drupal 7 version, but the tables of webfm will be in your migrated database.
Installing and configuring Elfinder in your migrated Drupal 7 site is easy, and it can use exactly the same file struture left over by webfm. You will also have to link it to your editor, in my case CKEditor, that was also easy.
The problem comes with the links that webfm created (of the type "/webfm_send/#" where # is an arbitrary number assigned by webfm.) If you don't want to end up with zillions of broken links in your site you have to fix those. If you have few nodes you can fix the broken links by hand, but then it's unlikely that you were using the webfm module at all, as a small site can work perfectly with a flat file system without any special document management.
The fix of the links, if you have a large site, involves working directly in the database so stop here if you don't dare, in any case you have to backup everything and know how to restore your database because for sure you will have to iterate a couple of times before everything works. This also presumes that you have phpmyadmin installed, but everything can also be done from a mysql prompt, so you need at least acces to a command line in your server, or some way of managing and running sql scripts in the mysql installation where your drupal lives.
Fixing the links was not very hard either, just some hard work (in my case 2 or 3 hours, depending on how long the scripts below take to run in your system). All the information is in the "webfm_file" table, there you have the # number that appears in the webfm_send link, and the actual path to the file in the file system of your server. These are stored in the fields "fid" and "fpath" respectively. The webfm_send links though are all over in different tables. So here is how I did it:
1) First locate all the tables where you have webfm_send links: I did this by going to phpmyadmin, and doing a search over all the tables for this string.: "%webfm_send%". In my site the tables and the number of times the link appeared, were:
23 block_custom 26 content_field_descripcio 9 content_field_informaci_confidencial 1 content_field_resum_de_lacte_si_ha_esta 2 content_type_capsula 1478 field_data_body 4 field_data_comment_body 26 field_data_field_descripcio 9 field_data_field_informaci_confidencial 2 field_data_field_mes_info 1 field_data_field_resum_de_lacte_si_ha_esta 1488 field_revision_body 26 field_revision_field_descripcio 9 field_revision_field_informaci_confidencial 2 field_revision_field_mes_info 1 field_revision_field_resum_de_lacte_si_ha_esta 19 locales_source 1 menu_links 2 webform_component
2) Now you have to run a script in the SQL tab of phpmyadmin. Choose one of the affected tables. Go to navigate and try to figure out where the webfm_send links may appear. These are typically fields of the "body" and "summary" of the element of the affected table. In some other tables they are in other fields, you may want to run some searches, but the easiest is to include all the text and varchar type fields, whenever it is not evident that the links cannot be there (a field called "type" for instance is unlikely to hold one of the links). In any case if you include a field with no type there is no problem either. For instance in the field_data_body and field_revision_data_body, which hold most of the broken links, the links are in the "body_value" and "body_summary" fields. Here is my script for the fiel_data_body table:
drop procedure if exists proc; delimiter // create procedure proc() begin declare done boolean default 0; declare path varchar(255); declare id int; declare cur cursor for select fpath, fid from webfm_file; declare continue handler for sqlstate '02000' set done = 1; open cur; block: loop fetch cur into path, id; if done then leave block; end if; set @from = concat('/webfm_send/', id, '"'); set @path = concat('/', path, '"'); update field_data_body set body_value = replace(body_value, @from, @path), body_summary = replace(body_summary, @from, @path); end loop; close cur; end//
The script is pretty self-explanatory. First it reads the pair fid/fpath. Then it creates a loop (in a very elegant way suggested to me in Stackexchange, but I managed to do it also with a "while" loop), then it converts fid and fpath into the form which will go in the actual link substitution. And finally the UPDATE clause does the substitution. The search and substitute may be slow, if you have a lot of content, but eventually it will complete.
3) You have to run the same for all the affected tables, just changing the table name for each case and including in the UPDATE clause the field or fields which could be affected in the table you are treating. This script could be converted into a function or something, but well, too lazy to do it.
4) When you finish you can do a search again on the whole database for the "%webfm_send%" fields, maybe you get still some links as me because they were already broken in the original site (broken in the webfm module already), but in my case I ended up with about 30 broken links and I have 10000 nodes.