Beware of Your Own Content: Do You Own the Data Export of Your Blog?
By Peter Boyd on October 22, 2015 in Content
We were recently hired to develop a new website for a law firm in Florida with more than 1,790 blog posts and 90 pages of core content. That is a lot of writing.
It would be best practices to migrate all the content to the new site. Normally, we could do this in an hour via a quick export and import tool. We would grab the old posts and upload them to the new WordPress content system.
Unfortunately, the current provider will only provide a static HTML copy of the website. The copy we were provided works as a stand-alone website, but cannot be imported into the new website. So, the only solution is to manually cut and paste each post one-at-a-time into WordPress. Not ideal. The project is easily 100 hours of work to set-up the blog posts again, even though they are already in a blog in a similar database.
Copyright and Data Export Are Not the Same Thing
The firm wrote the content and posted it themselves using the online CMS, so they own the copyright to the content. They have every right to the data on cancellation… but, in what format?
The prior development team is offering a static copy of the website that they save using their own software. They website is delivered to us, the new web design company, in the form of an End User Interface (EUI) zipped file, which in this case is more than 1,880 individual HTML web pages.
What we really need is a data export in a CSV or XML file. A CSV of XML file would allow us to import the data to the new site automatically. Unfortunately, that is not offered. So, we have to manually cut and paste 1,790 blog posts and 90 pages of content into WordPress. Ridiculous. Time. Waste.
Why is an EUI Useless?
An EUI is only good if you want a static copy of your website on a new server and are not really going to update it ever again. It is not great for three reasons:
- If you are transferring to a new content system, like WordPress, you have to manually rebuild all pages (i.e. cut and paste).
- Even if you wanted to use the exact same website, you would still need to do some major rebuilding of the forms on all pages, menus, and overall global updates would be a pain in the future.
- There are way better tools. For example, Site Sucker for Mac allows you to grab any website in about five minutes time.
About Vendor Lock-In
Web developers do not like losing clients. I understand. I am a web developer and I don’t want to lose clients either. It is in our interests to make it hard for any client to transfer. However, not providing a data export of the clients own text in an easy to import format is going too far.
Clients will rebuild the website using the manual cut and paste so it just wastes time and money. In this case, probably about 100 hours of work to get all the content imported.
Note: The hour count is based on an estimate of three minutes to get every page set-up, data cut/pasted, and checked out by our quality assurance team. We have done this a few times and the three minute rule applies for most pages, although sometimes you can get it down to a minute, so long as the content is simple enough.
Check Your Contract …. Now!
In this modern era you should be demanding that your web development team provide the ability to EXPORT of all your content. The export should be in a format that can easily be imported into any standard SQL database (CSV or XML would work). The clause should be included in the contract BEFORE you sign your agreement and build your site. I am not saying this should be a free service, but it should be made available at price.
If you are signing up for a new website with ANY web development team, make sure you have these rights built into the contract. It should take no more than a few hours to export data of all the blog posts and import them into the new database. Importing the data into any new database or content system is a routine task and shouldn’t take more than an hour or two of work, depending on the data mapping of fields.
These are things you should demand from your current developer and be part of your contract:
- Export – You need the option of an export of the entire site database. You may need to pay additional for this, as it could take time to set-up an export, but you should at least have the option. Even with proprietary databases, you should be able to get a CSV or XML of all your data to import into a new system.
- SEO/SEM – All title tags and meta descriptions should be included. It makes no sense for a developer to withhold this data as it is part of your website, but it happens.
- Source Files – You should have access to your original PSD concepts for the website.
- Images/Video/Audio – All images should be licensed to your firm. You need access to the original videos and audios.
- Static Copy – Honestly, you never really need a static copy of the website. You can get one by using any Site Sucker program.
Go check your contracts … right now! Make sure that not only do you have access to the copyright in your text, but you have the right to migrate it via a data export. Save yourself from vendor lock-in by using open-source content platforms or platforms that allow you to easily export data.
