I hope I'm understanding your situation correctly. If I'm not, leave a comment and I'll clean it up a bit.
In your situation, I'm not sure how well A/B testing will work - I'm concerned with being able to get usable results. There are two problems to overcome - getting statistically valid results and then understanding those results.
The first problem that you need to see is that the ~1000 people who are using your service aren't your entire user base and you can't be sure that they are representative of your users. Just because these 1000 users show certain tendencies in A/B testing doesn't mean that other groups of users will also have those tendencies. And I think that also clouds the statistic validity of the results because you have improper samples.
You also have two categories of people who use your particular service, and who knows how many who use the resold systems. In your system, you have the frequent and the infrequent users. But how about in the other deployments? If your changes would affect them as well, you might be impacting their ability to achieve their goals with absolutely no data on their user experience in A or B.
And understanding any results you do get will be difficult, especially if you deploy your A/B testing across multiple deployments of your service. If you are gathering data from several distinct populations, you might see that you achieve your desired results with A in some and B in others - you then have to decide if this is indeed accurate and then decide what to do with it.
Honestly, in this case, I would recommend surveys. Find out about the background of you users - age range, gender, computer experience, profession - and how they use the software. Then, find out what features they like or don't like, what features are easy to use or not, and so on. This survey should go out to as many people as possible - both people who use your deployment and people who use other deployments.