We recently picked up a new six surgeon practice. Our first interaction with this client was a request for us to move their website from their previous host and developer. We moved the site to one of our servers and found out that a large portion of the site functionality did not actually reside on the website. For much of the functionality, the site was accessing an external website which the former developer controlled. We brought the issue to our clients attention and they were surprised by the news. They knew nothing about this other website and since they paid a project price for the site to be developed, they assumed they owned the site and could transfer all functionality.
I am not a lawyer but in many ways I believe their assumptions were correct. However the biggest problem they will face is that these were only assumptions. They have no documentation to backup ownership of the site AND functionality and they have no statement of work proving what they paid for.
We have been building websites for 13 years and have never ran into an instance like this before. So I don’t think this is a common problem. However, it doesn’t mean you shouldn’t take some simple steps to ensure you won’t face the same problem. In my recommendation, those steps would be:
1. Execute clear statements of work which define ownership of all original work and the finished product
Ownership in the web world is a tricky topic. Websites today are built with dependencies on operating systems, webserver applications, database applications, frameworks, and a large assortment of preexisting libraries. You will never have ownership of the Apache webserver code or Microsoft Windows or many other programs upon which your website depends. However, you can retain ownership of any original work a design/development company provides for you. And you can also own or have copyright to the finished product look, feel and functionality. This can be clearly stated in the statement of work.
2. For custom development work maintain a clear Systems Requirements Specification
When you move a site, your new host or development company will have little idea as to what you have had developed in the past. They will be able to see the results of the development but they won’t have access to the requirements around any development work unless you maintain a clear System Requirements Specification (SRS) with your development company. This document will save countless hours of systems analysis and reverse engineering when your site must be moved.
3. Put in place a clear hosting agreement ensuring continued site functionality upon transfer of hosts
Moving a site is not always an easy process. Sometimes there are dependencies and licenses that need to be dealt with or purchased. However, that doesn’t mean you can’t have in your possession a clear plan for how your current developer/host plans to deal with these dependencies to make a transition away from them as smooth as possible. There may be complications to a site move but that doesn’t mean you can’t have written agreement beforehand from all parties on how complications will be handled.
Some may think they are happy with their current host and have no plans to move their site so they have no need for these precautions. Last year we received a new client because their site had to be moved within 1 week because the previous host was closing their doors. They had no time to plan the move and gather any of this information. We simply had to move what we could and hope for the best. Fortunately in this case all worked out just fine and no data or functionality was lost.
One thing for sure is that in all the years we have been in this business we continue to learn about new situations and new circumstances. I don’t expect that my list is exhaustive on ways to protect your practice but from my experience this is a good starting place. As usual these issues never seem to have importance until something happens and they are viewed in hindsight. I’d love to read your comments below on anything I might have overlooked.