3 ms·

My thought is that it is "dirty" to not allow your customer to easily export their data from your project. If a customer chooses to use a competing product, an

My thought is that it is "dirty" to not allow your customer to easily export their data from your project. If a customer chooses to use a competing product, and you make it hard for them to do so in order to keep them, you've already gone from being a help to being a barrier to your customer. If someone else comes along and removes your artificially erected barrier at their expense, so be it. Perhaps next time, it would pay to work with your customers, and not against them.

dpcan 17y ago
This is sometimes easier said than done. We have a system that is made up of about 30-40 tables of associated data. The software itself allows many levels of reporting on the data, and we take nightly snapshot backups of the data for restores. So, the customer need not worry about the integrity of their data or getting it back out in a meaningful manner. However, developing a system of export would not only be extremely expensive, but would be done so to allow our customers to leave. We are working on an API that would allow some interaction with the data, and I suppose someone could write a form of export tool from the API if they choose, but I don't think we are going to do this. I can see how important it might be to have export tools for a contact manager, or other small, single-use apps, but it's just not realistic, nor does it make good business sense when you have massive data sets and invest greatly into support and data backups/management.
- run4yourlives 17y ago
  The choices you make for you and your app are yours alone, and each must be weighed against your other needs. I didn't mean to imply that exporting your customer's data was an easy or priority job. However, you don't operate your business in a sandbox. We're moving, ever so slowly into a world where ownership of data is becoming a very real concern for many of your would be customers. You will run the risk that either a new customer finds your terms unacceptable, or even worse, that your competitor does this extremely expensive task for you. There are many situations and each deserves it's own investigation. I'm merely stating a design principle that is good to practice.

dpcan 17y ago

This is sometimes easier said than done. We have a system that is made up of about 30-40 tables of associated data. The software itself allows many levels of reporting on the data, and we take nightly snapshot backups of the data for restores. So, the customer need not worry about the integrity of their data or getting it back out in a meaningful manner. However, developing a system of export would not only be extremely expensive, but would be done so to allow our customers to leave. We are working on an API that would allow some interaction with the data, and I suppose someone could write a form of export tool from the API if they choose, but I don't think we are going to do this. I can see how important it might be to have export tools for a contact manager, or other small, single-use apps, but it's just not realistic, nor does it make good business sense when you have massive data sets and invest greatly into support and data backups/management.

run4yourlives 17y ago
The choices you make for you and your app are yours alone, and each must be weighed against your other needs. I didn't mean to imply that exporting your customer's data was an easy or priority job. However, you don't operate your business in a sandbox. We're moving, ever so slowly into a world where ownership of data is becoming a very real concern for many of your would be customers. You will run the risk that either a new customer finds your terms unacceptable, or even worse, that your competitor does this extremely expensive task for you. There are many situations and each deserves it's own investigation. I'm merely stating a design principle that is good to practice.