If you need assistance, please make an effort to answer the questions posted here to get the information necessary to solve your problem, and to answer those questions exactly as posed.
What is the old URL? http://www.example.com/com/mem/sitename What is the new URL? http://www.example.com/sitename What is the actual server filepath to user files? ___________
If you remove "/mem" from your URLs, then your site cannot have any subdirectories added to it, because there will be no way to tell if a request is for a 'support' subdirectory or for a 'user.'
By putting the usernames in the top-level directory-path, you effectively allow users to control what you can and cannot name your subdirectories in the future. That's a bad plan. Consider using user-subdomains instead, if your server has (or can have) a unique IP address. Otherwise, I strongly recommend that you keep the "/mem" path in the URL. Or shorten it to just "m" if you like, but leave something in the URL that distinguishes 'user' requests from requests for 'real' subdirectories.
Note that on large sites where many, many subdirectory-paths can be created, it is common to split them up by intial letter or letters in order to avoid serious performance problems that occur when a directory contains too many files or subdirectories. Thus user Adam's URLs all start with /a/adam/ and user Bill's URLs all start with /b/bill. In this case, the code can easily key off "single-letter" subdirectory name to tell whether a request is for a user subdirectory or a 'real' subdirectory. Just another option here, if you're planning for success...
Why I asked for three different paths above:
You need to redirect the old URL to the new URL.
You may need to rewrite requests for the new URL to the correct (old) internal filepath.
You may wish to redirect direct client requests for the internal filepath back to the new URL.
Only by knowing all three paths is it possible to determine the proper solution.