Acquiring WordPress Plugins

Over the last year, I acquired two premium plugins and one free plugin from other developers. I’ve written about those acquisitions briefly here and here.

I feel like this is something that can, and perhaps should, happen more frequently if people knew what to expect from the process.

However, a lot of times developers might not know what questions to ask, or what to expect when thinking about acquiring WordPress plugins. The “fear of the unknown” might make it too difficult for some to take that leap. This is especially true with developers who are great at the code they write, but may struggle with other areas of their business.

What I want to do is write about my experiences and share any pain points, things I wish I did, or just general good advice when acquiring WordPress plugins. Hopefully this can serve as a guide for anyone who is thinking about an acquisition (or sale) and alleviate some of those fears.

In this post, I’ll cover:

• Why someone might want to acquire a WordPress plugin.
• How to find a plugin to acquire.
• Tips for how to value a plugin.
• How to handle existing customers.
• What to do with affiliates.
• Technical considerations on how to transfer ownership.
• Legal considerations.

Why Acquire a WordPress Plugin?

Whether you just started getting into development, or have been developing WordPress plugins for years, acquiring a plugin has some great advantages.

First, you don’t have to spend tons of time developing the plugin from scratch. There is a lot that goes into selling a plugin. It’s not all about throwing some code together and seeing if it works.

You need to identify a problem that needs solving. Then code a solution for the problem that works well and is intuitive enough for someone to use effectively.

You also need to market it. That’s a whole other can of worms that requires identifying a target market, knowing the price that market is willing to bear for your solution, and learning the “language” of your target audience.

Of course, I’m over simplifying this whole process and some of those steps are probably out of order. The point is that there is a lot of work that goes into creating a plugin from scratch. Each of those tasks requires many hours of work to do well. You may not even have all of the skills needed to do each task well on your own, so you may need to hire help. Even after you’ve done it all, there is no guarantee that anyone is going to buy your plugin.

Acquiring a WordPress plugin eliminates a lot of the risk. While you can’t eliminate all of the risk, you can reduce the risks involved.

When acquiring a WordPress plugin, you don’t need to do much work to figure out if the plugin is solving a need. Just take a look at the financial reports from the previous developer (more on that later). They will tell you if people are buying the plugin or not. “Money talks” as the saying goes. If the company has a product that is selling well, it is probably addressing a need that the customers want solved.

On the code side, the code is already there. You’ll have at the bare minimum an MVP on day one that you can start selling. Sure, there will be updates and new features you’ll want to add in, but the plugin you’ll be getting should be stable enough to begin selling on day one at roughly the same volume that the previous owners were selling it at.

A lot of the marketing leg work will also be available to you. The previous owner likely had some time to play with prices to see what the market is willing to pay. They probably tweaked their sales message on their website, and built up an email list of past and (hopefully) potential customers as well. You’ll be able to use all of that information on day one so you can hit the ground running.

How To Find Plugins To Acquire

To be perfectly honest, I came across the plugins that I acquired because I may have spent a little too much time on social media.

Who says social media is all bad, right?

I happened to be following the right people on social media who ultimately posted that their plugins were available for sale. One way to find plugins to acquire is to connect with the people who have the plugins you’re looking to buy on social media, or in person at conferences like WordCamps or meetups. Following people who run or work at plugin companies is a great place to start.

I happen to follow Pippin Williamson on Twitter, so I saw this tweet shortly after he posted it. I was able to reach out, and after a brief negotiation period, we were able to agree to a deal.

For both of the plugins I purchased, I was able to talk to the other party in the Post Status Slack group. If you’re not already a Post Status member, it is a pretty good resource that I’d suggest joining. A lot of people in the WordPress community are members there and it is an easy way to get in touch with people if you are looking to buy or sell a plugin. You can also use email/phone calls/Zoom or whatever other communication method you choose. A lot of people use Slack these days, which is why I mentioned it.

You can also browse the adopt-me plugin tag on the WordPress.org repo. The plugins you’ll find there are ones where the developers are no longer willing or able to support the plugin and who want to find a new home for them. There just might be something that pops up there that would be a good fit for your needs.

However, if you adopt a free plugin on WordPress.org, you won’t be able to monetize that plugin the way you can a premium plugin. There might be an opportunity to develop a premium version, or “freemium” version, of the free plugin though.

This post isn’t really geared towards free plugins, but it’s a consideration worth mentioning since many premium plugins have a free version available as well.

Plugin’s Reputation

Before acquiring a plugin you might want to dig into some research on it’s reputation. Not just the software of the plugin, but also the developer(s) and support team that is currently behind it.

Regardless of the current reputation, your actions after the purchase are what can really make or break the perception of the transaction.

For example, if the current plugin doesn’t have the greatest reputation with customers for having responsive support, you can promote your existing support ratings to customers so they get a better feel for the new owner.

On the other hand the plugin might be sold by a well known and respected developer to a relatively unknown developer. As the buyer, you’ll have some work to do in order to ease the mind of the customer. They may have only purchased the plugin from the original developer over another competing plugin based on the developer’s reputation.

When I bought Full Screen Background Images from Pippin Williamson I was concerned about my status as a developer relative to Pippin’s. The first thing I did was offer a discounted price for the first few weeks that I was selling the plugin. This lowered the perceived risk that customers had when purchasing from a relatively unknown developer. The next thing I did was offer the best support I could. I was as prompt with replies as possible, and I went above and beyond with the replies that I gave. Finally, when the sale of the plugin was finalized I told existing customers some of the improvements I would be making to it. Within the first month I had three new features included with more following in the months after. I stuck to my word.

In hindsight the initial discount was probably unnecessary. I think the price point was fair enough that the price wouldn’t sway new customers. I didn’t offer a discounted price with Quick Checkout after learning that lesson, however I provided the same level of support.

TL;DR: You may have to do a little work to earn trust.

Question Why A Plugin Is Being Sold

One important thing to consider is why a plugin is being offered for sale in the first place.

In the case of Full Screen Background Images, Pippin already had his hands full with Easy Digital Downloads, AffiliateWP, and Restrict Content Pro. Those were generating lots of revenue, and taking up a large chunk of his time. In comparison Full Screen Background Images brought in a small fraction of the revenue that those others brought in, and it still needed to be supported. I understood why Pippin wanted to sell the plugin – to free up his time to focus on his core plugins. That was an acceptable reason for me since taking over a plugin that had been somewhat neglected presented an opportunity for growth.

For Quick Checkout, the original company that developed it was WordImpress. They recently rebranded to Impress.org in an effort to target non-profits with their core GiveWP plugin. It made sense that they sell off other plugins that were not a part of their core focus.

You may find someone who is trying to sell a dud of a plugin though. Keep an eye out for poor sales, bad reviews, and other “red flags” before jumping in.

How To Value A WordPress Plugin

This is a tricky topic, because there are a lot of variables that go into valuing a plugin. Since there is so much involved, I’m not going to tell you to value it at a certain multiple of sales and end the story there. I’ll give you a few things to consider when negotiating a price. Those considerations will help determine what price you might want to pay for the plugin.

Revenue

If someone is serious about selling their plugin, they’ll have the revenue numbers available for you to review. Ideally you will be able to see the revenue from each year that the plugin was sold. If not, I would suggest looking at a minimum of three years of revenue numbers (assuming the plugin was being sold for that long) so that you can identify trends to find out if there are any large spikes or dips in sales over the years.

Sellers and developers, this paragraph is specifically for you. If you think you might ever sell one of your plugins at any time in the future, do yourself a favor and keep separate records for each of your plugins. Record the amount of time, and perhaps more importantly the money that you have spent on development, support, marketing, and all the other related tasks for each of your plugins. You will also especially want to read the section below on payment processors.

Net Income or Gross Income?

Whether you look at the net or gross income really depends on your situation. A large part of the expenses involved will likely include wages paid to other developers, marketing staff, and support agents. If the company you’re acquiring the plugin from has a drastically different set of employees than you do, it may make sense to look at one set of numbers over another. It may also be worth considering if your company will need to grow in order to handle the added support, marketing, and development that will be required.

Here is an example: If you are a solo developer who is buying a plugin from a company with multiple developers, support staff, etc. their costs are going to be drastically different than yours. You may not need to pay developers, and you may be able to support the plugin on your own. Sure this will take your own time, but you may not need a financial expense to maintain and support the plugin. In this case gross income is probably sufficient. You will, however need to identify how much time the other company spent on support, development, and marketing so you can determine if that is something you, as a solo developer, can handle.

On the other hand, if you have a similar team makeup (developers, support staff, etc.) you might want to know what you’ll be adding to your payroll costs.

Of course there could be other expenses too like PPC ads, retargeting ads, or content marketing. If a bulk of their sales come from those avenues, you’ll want to know how much was spent, and hopefully get copies of the marketing materials that worked best for them. If content marketing was a heavy driver of sales, you’ll want to acquire the content pieces along with the software itself.

Knowing their revenue, whether gross or net, is a good starting point for any valuation.

Renewals

You will want to know whether or not the plugin is selling on a subscription basis where customers renew their license periodically (typically annually), or if it is a one-time “lifetime” purchase. If the customers renew their license annually, you will want to know if it renews automatically or if customers have to manually renew.

When a customer has to do something manually, it is far less likely that they will do it than if it happens automatically. This is especially true with renewing software licenses.

Licenses for plugins can renew in one of three ways that I can think of:

• Automatically: This is the best scenario, because on day one you will have a built in revenue source from existing customers that will occur immediately without having to wait a year for new customers to renew.
• Manually: While not quite as ideal as automatic renewals, manual renewals are still better than nothing. Just don’t expect a ton of the customers to renew. For reference, in the year since I acquired Full Screen Background Images the renewal rate was about 4% (all were manual renewals at the time I acquired the plugin). On the other hand some of my other plugins have >50% renewal rate with automatic renewals.
• Lifetime (or no renewals): This is the least optimal since all of those previous customers will have access to the product and support with no reason to pay you anything in the future. Of course, you could create a new addon that is not included in the original “lifetime” purchase with a great new feature to sell to those original lifetime customers. You might also be able to leverage the existing customer base to promote another plugin or service you offer.

You’ll want to factor the expected renewal rates into your valuation, which you can more accurately do by understanding the nature of the renewals.

Payment Processors

How payments were processed is something that I didn’t consider with any of the plugins I purchased, so I can’t say for sure how all this will work. I’ll give you some considerations though.

If a company has automatic renewals, the renewals are processed through their payment processor (i.e. Stripe, PayPal, etc.) automatically. The API from those processors usually is what triggers the license renewal on the website to extend the expiration date another year.

If the company you’re purchasing the plugin from has a separate account for each plugin they sell, it should be possible for them to transfer the account to you. This would allow all of the automatic renewals to continue without interruption. This is the most ideal situation.

On the other hand, if the company has one account where sales from all of the plugins and anything else their company sells, they won’t be able to strip out the customers for the one specific plugin you’re acquiring to transfer to you. That makes all of the auto renewals less valuable to you because they essentially become manual renewals to you (the buyer), for the first year at least.

Here are some processor specific instructions for how to transfer an account:

• Stripe
• PayPal – The article doesn’t mention this but you’ll also need to get the login details for the account from the previous owner.

UPDATE: I recently had to go through this process with Stripe. One thing to keep in mind is that Stripe doesn’t give you a way to remove your bank account before transferring ownership without there being a bank account associated with the account. The best way to do this, according to the Stripe support agent I spoke with, is to add the new user to the account as an administrator. Have them add their bank account information to the Stripe account, then remove your bank account information. Finally, transfer ownership of the account to the new user using the instructions in the link above.

UPDATE #2: I also had to do this with PayPal. The support agent I spoke with gave the following instructions:

Proof of SSN, a letter head of the business where the name should reflect.
You can try using the link: www.paypal.com/il/uploaddoc and follow the steps below to upload your documents securely to PayPal:
Here’s how to change the name of your business.
– Click the Settings icon next to “Log out.”
– Click Change next to “Name.”
– Select the reason you are changing your business name. (Note: I selected “Your contact name has changed”)
– Click Continue to complete the instructions.

There are other payment processors you might be using, but PayPal and Stripe tend to be the most popular. You should be able to find similar instructions for other processors.

This probably goes without saying, but you’ll also need to change the bank account information and other business related information (business name, tax ID number, etc.) on the account so that deposits go to your account and not the old owner’s account.

You will then make sure your site is using the API keys from the account, and any required webhooks are enabled in the payment processor.

With all that said, if you think you might ever sell a plugin, keep the accounts for your plugin separate from any other revenue streams you might have. Whether that means other plugins, products, or services, it is just easier to sell if everything is kept separate.

WordPress Plugin Valuation Examples

As you are reading this blog post, hopefully you are realizing that there are a lot of things to consider when valuing a plugin. I can’t possibly consider every unique scenario you might come across, but I want to at least give you some ideas on how to calculate a value that would be reasonable to pay for a plugin.

The 1.5x Revenue Valuation

A common place to start with valuing a plugin is 1.5 times the plugin’s annual revenue. A simple valuation would be made by taking the sum of the last 12 months revenue and multiplying by 1.5.

To illustrate, let’s say a plugin had the following revenue numbers:

• 2018: $10,667
• 2017: $9,987
• 2016: $10,412

Since those numbers are relatively consistent, I think a fair starting point for a valuation would be $16,000, or $10,667 * 1.5.

On the other hand if the plugin had inconsistent sales, it might be worth taking an average of the last 3-5 years of sales to come up with your valuation.

• 2018: $13,367
• 2017: $4,186
• 2016: $10,447

Ah! How do you make sense out of that big of a dip in 2017? I’m sure there is a reason, but it’s also possible that 2019 will see a similar dip – maybe the plugin lists results from the Olympics, which occurs every 2 years. Or the customers are just afraid of odd numbered years – who knows? For this scenario, I might suggest averaging the revenue to come up with a valuation of $14,000, or (($13,367 + $4,186 + $10,447) / 3) * 1.5.

If sales are inconsistent but trending upward, which might be the case with newer plugins, you would probably be safe to use the most recent year’s revenue like in the first example.

Adjustments To The Valuation

The 1.5x example above is just an estimate to come to a starting point for a fair price. However, there will likely be other factors that would cause you to adjust this price up or down.

For example, maybe there is a hypothetical plugin that had great sales all the way up until a similar feature was introduced in WordPress core. Then all of a sudden, customers realized they could get the same benefit for free. Sales start to drop significantly, and the plugin’s developer decides to sell it to salvage whatever they can financially. From the buyer’s perspective this plugin doesn’t have a 1.5x value anymore. It probably doesn’t even have a 1x value. A potential buyer would need to seriously consider whether or not the plugin has the potential to bring in enough revenue to justify any cost.

On the other hand, let’s say an existing plugin provides some functionality that an upcoming government regulation is going to require every website to do. Hypothetically, let’s say this functionality only exists in this plugin, and while sales are good, a potential buyer knows that they will likely get better due to this upcoming regulation. A potential buyer might consider a 2x, 3x, 4x, or higher valuation depending on how much demand they are forecasting and other competitors that might enter the market in the future.

Other factors you should consider include whether or not the plugin has automatic renewals, the reputation of the previous developer, customer reviews, cross-sell potential, and your ability to add features to create more value.

How To Handle Existing Customers

Existing customers are those people who purchased a license to the plugin from the original company, still have a valid license, and will likely be expecting support and updates while their license is still active.

There are a few ways that I can think of how to handle existing customers.

Not Providing Support

While likely unpopular, one option is to simply not provide support to those customers because they aren’t technically your customers. That’s certainly one way to go, but I wouldn’t recommend it.

When the customer purchased the plugin, they were likely guaranteed updates and support for a certain period of time. In the WordPress plugin ecosystem that period is typically one year. Just because the company they bought from decided to sell to another company shouldn’t mean they lose access to these benefits. Regardless of what you think of this sentiment, this will inevitably be what the customer feels. By removing access to these benefits (that they paid for) you will leave a bad taste in their mouth for your company.

You can structure this another way though. If you feel like it isn’t your responsibility to support those customers, you can ask the company you are purchasing the plugin from to continue supporting their customers until the customer’s license expires. This would mean the selling company would continue support for a year, and after that the customer would renew their license with you at which point you’ll pick up the support.

While this is better than completely shutting off support to these customers, it is less than ideal because the other company won’t have control over updates you make. Plus, you should be in control of communication with the users of your plugin so that the messaging is consistent and you learn the pain points that customers are having with the plugin so you can make it better.

Providing Support

I have always agreed to provide support for any customers with a valid license of a plugin that I acquired regardless of who the customer purchased the plugin from.

If I were the customer, I would respect a company much more if they provided me with great customer service without nickel and diming me. If I got grief over a support question just because I paid a different company for the plugin, I’d be less likely to want to do business with the company in the future, which includes renewing my license.

Bottom line, I think providing support to existing customers with a valid license is the right way to go.

Refunds

If the company you are acquiring the plugin from continues to sell up to (or near) the date that the plugin trades hands it is possible that one of their customers will ask you for a refund. This is something I didn’t really consider and luckily didn’t have to worry about, but it could happen.

I would recommend putting into your contract that the original owners of the plugin will issue refunds within their normal refund window to anyone who paid them for the plugin. This window is typically somewhere between 14-60 days, so it isn’t a long-term consideration, but still something to think about.

Work out a message to those customers that informs them how to get in touch with the old owners to request the refund. Be sure to communicate to the old owners too so they know the refund request is coming.

The other option is to issue the refund yourself. However, if you don’t have access to the customer’s payment record in the original payment processor this will prove to be rather difficult. See the section above on payment processors for details on how you might be able to maintain the original owner’s account.

I guess the best way to handle refunds is to have whoever retains control over the original payment processor account issue the refund.

What To Do With Affiliates?

Before you acquire a plugin, you might want to find out if there are existing affiliates who are actively promoting the plugin.

Try to get a list of these affiliates and reach out to them encouraging them to re-join the affiliate program if you are setting a new one up for the plugin. If you’re maintaining the original affiliate program you still might want to reach out to those affiliates, which can benefit you in a few ways.

First, you can introduce yourself to the affiliates and let them know about plans you have for the plugin. This can help with content creation on their end as they plan out blog posts, social media, podcasts and other content. They might even be interested in promoting the new owner of the plugin, which can help kick start sales in the first few weeks.

Most importantly though, you’ll also benefit if they update their referral links to point to your new site. In a plugin acquisition, it is possible that you won’t be selling on the same site as the original company. If that is the case, the old affiliates will be sending traffic to the wrong website. Even with a redirect in place (more on that below) the affiliates may not get credit for the sale and may become upset that they aren’t getting paid for the traffic they send to you.

Technical Considerations

Depending on how you are structuring the sale, the technology you and the other company use, and a number of other considerations there can be many technical issues you need to factor in.

Transferring A Domain Or Website

If the plugin was sold on it’s own dedicated website, it would probably make sense to all parties involved to continue selling on that site. This would probably have the least amount of friction for the buyer, seller, and existing customers.

This would just involve transferring the website files and database as well as ownership of the domain to the buyer.

If for some reason the domain can’t or won’t be transferred to the buyer, the next best thing is to transfer the content of the existing website. The benefit here is that all of the sales records, customer accounts, page and post content are already set up on the site. The traffic to the current site can then be redirected to the new site using 301 redirects.

If none of that is possible, it may be required that the buyer set up a new website on a completely separate domain from scratch. While this isn’t ideal, it isn’t a show stopper either. This is what I did when purchasing Full Screen Background Images and Quick Checkout. Again, 301 redirects should be used by the original owner to send relevant traffic to your new site.

Full Screen Background Images was originally sold on PippinsPlugins.com which, in addition to that plugin, hosted a number of other things like a membership site, other premium plugins, tutorials, etc. Transferring the entire domain and website wouldn’t be possible in this case. Similarly, Quick Checkout was sold alongside other plugins on the same site, so it wouldn’t be possible to separate it from the main site easily.

The next best thing is to import existing customers from the seller’s original site to the buyer’s new site.

How To Import Customers From Seller’s Site

I was lucky in that all of the plugins I bought were originally using Easy Digital Downloads, which is the same e-commerce platform I use. There are other e-commerce platforms like WooCommerce, Freemius, Gumroad, and more that you might have to deal with though. For this tutorial’s purpose I’ll stick to Easy Digital Downloads.

If both the buyer and the seller are using Easy Digital Downloads (EDD) to sell the plugin, life is a little bit easier because EDD has a tool to export and import payment records.

Note: EDD 3.0 isn’t available quite yet, so these instructions are for EDD 2.9.x. I’m hoping to update this tutorial with 3.0 instructions when it becomes available.

On the seller’s site, go to Downloads > Reports > Export tab. In the Export Payment History section, choose a start and end date. This will ideally be the date the seller began selling the plugin and the date of the last sale respectively. Choose Complete if you aren’t interested in exporting failed transactions, refunds, etc. otherwise leave the box at All Statuses. Then click Generate CSV.

This will create a CSV report of all payments made on the site in EDD between the dates specified. If the seller has sold other plugins, they will need to open the CSV in a spreadsheet program like Google Sheets, Microsoft Excel, etc. to delete the payment records that are not related to the plugin that is being purchased. I recommend a spreadsheet program because you can easily sort the “Plugin Purchased” column, then delete the records that are not needed.

Now, it is important that you (the buyer) has a download product already set up in your EDD shop. Make sure it has the same exact name that the seller used, and the same price options if it is a variable product. This is because when you import the payment history, it will attempt to make a payment record and add the plugin as the item purchased. If the plugin doesn’t exist on your site, it won’t be able to add it to your customer’s payment records.

Note: the seller can also export download products to a CSV on the Downloads > Reports > Export tab. They can edit it to exclude any other plugins that aren’t included in the sale. The buyer can import the download products CSV file in the Downloads > Tools > Import/Export tab.

The buyer can then take the sellers payment history CSV file and import it to their site. They can do this by going to Downloads > Tools > Import/Export tab. In the Import Payment History section, upload the CSV file then click Import CSV.

This gets everything nearly all imported, but it isn’t quite complete. Unfortunately, no user accounts (i.e. WordPress users) get created on the buyer’s new site when importing through EDD. So while you have customer records, they have no way to login to your site to view their purchase history, get their license keys, download the new version of your plugin, etc.

How to Create WordPress Users From EDD Customers

The easiest way I found to do this was to loop through a list of Easy Digital Downloads customer IDs, check to see if the user exists already, and create a new account if it doesn’t. On a new site, it won’t.

add_action( 'admin_init', 'create_users_from_edd_customers' );
function create_users_from_edd_customers(){
	// Get the comma separated list of EDD customer IDs from the query string
	$customer_ids = array( 1,2,3,4 );
	// If we haven't then start creating users.
	if ( $customer_ids ){
		global $wpdb;
		foreach( $customer_ids as $customer_id ){
			// Sets the EDD customer table
			$edd_customer_table = $wpdb->prefix . 'edd_customers';
			// Get all customers from the table
			$customers	= $wpdb->get_results( $wpdb->prepare("SELECT * FROM " . $edd_customer_table . " WHERE id=%s;", $customer_id) );
			if( $customers ){
				// Loop through customers to create the user accounts
				foreach( $customers as $customer ){
					$email	= $customer->email;
					$name	= $customer->name;
					// Check if the user already exists
					if( null == username_exists( $email ) ){
						// Generate a random 12 character password with special characters
						$password	= wp_generate_password( 12, true );
						// Create the user
						$user_id	= wp_create_user( $email, $password, $email );
						// Add the user's nickname (required) as their name from the customer record.
						wp_update_user(
							array(
								'ID'       => $user_id,
								'nickname' => $name
							)
						);
						// Get the user
						$user = new WP_User( $user_id );
						// Set the user's role to Subscriber
						$user->set_role( 'subscriber' );
					}
				}
			}
		}
	}
}

Verifying Customer Accounts

In Easy Digital Downloads if someone makes a purchase as a guest, their email address gets associated with the purchase. If a customer then creates an account with the same email address, they are asked to verify their account via email so that their past purchases can be associated with their new account.

When we imported the purchases on our site, we essentially made “guest” purchases for all of the customers. We then created user accounts with the same email addresses, which set each of those users up as needing to verify their accounts. This is a little bit cumbersome, and confusing to customers.

Easy Digital Downloads gives two methods for verifying customer accounts:

1. Have the customer verify their account the next time they login to the account on your site. In my experience, this is something that many customers have had trouble with, and in my opinion is an unnecessary step.
2. Manually verify each account. This requires that you manually click on each customer’s profile (Downloads > Customers) and click the verify link. On a site with a handful of customers this isn’t so bad, but if you import thousands of customers this would take forever.

To get around this, we can use a little function that will loop through each user ID that is set to need verification, and run their user ID through Easy Digital Downloads’ edd_set_user_to_verified() function. This is the function that Easy Digital Downloads uses when you manually click the verify link in each customer’s account anyway, so it is a much faster way of accomplishing the same thing. Plus it is less confusing for your customers.

add_action( 'admin_init', 'verify_all_customers' );
function verify_all_customers(){
	$users = get_users(array(
		'meta_key'     => '_edd_pending_verification',
	));
	foreach( $users as $user ){
		edd_set_user_to_verified( $user->ID );
	}
}

How to Handle Software Licenses

If you are acquiring the whole site, licenses won’t be an issue. If you are following the methods above to import payments, you will want to read on in this section.

When you import purchase history to the new site, all brand new license keys are generated for each purchase if you are using the Software Licensing extension. This is a bit inconvenient, but you can inform your new customers how to find their new licenses in their account in your “welcome” email to them. They will need to manually download and install the latest version of the plugin anyway because the version on their site will still be pointing to the original developer’s site for updates.

Another issue you might run into is if you are using EDD Software Licensing and Recurring Payments together. There is nothing wrong with the two of these plugins used together, however there is a small inconvenience when you have the Limit File Downloads checked in the Recurring Payments settings.

The issue is that none of the existing customers that you import to your site will have an active subscription if they didn’t pay on your site. If you purchased the whole site from the seller, then this is a non-issue.

The Limit File Downloads option requires users to have an active subscription in order to download files associated with a recurring product. If none of the existing customers have a subscription, they won’t be able to download the plugin from their account on your site.

There are two fixes or workarounds for this.

1. Uncheck the Limit File Downloads box in the Recurring Payments settings.
2. Use a bit of code to provide access to users who do not have a subscription to your product at all. This doesn’t mean you should provide access if their subscription is expired. It just means that customers will get access if they have no subscription at all, which likely covers all of the existing customers. You may have some older customer who shouldn’t have access that now will, but I figure that you have to weigh the benefit of allowing customers who should have access to download the plugin with the cost of a handful of people who shouldn’t have access being able to download it.

add_filter( 'edd_recurring_download_has_access', 'sd_grant_access_to_download_without_subscription', 10, 4 );
function sd_grant_access_to_download_without_subscription( $has_access, $user_id, $download_id, $is_variable ){
	$subscriber	= new EDD_Recurring_Subscriber( $user_id, true );
	// Only want to check for the one product with ID 123. In case there are ever any other products.
	if( 123 == $download_id ){
		// Check if $subscriber has a subscription to your plugin
		if( !$subscriber->has_product_subscription( 123 ) ){
			// Grant access
			$has_access	= true;
		}
	}
 
	return $has_access;
}

How you implement this is up to you.

You can code this into a custom plugin and then delete it after the one year anniversary (or however long licenses expire) of owning the plugin. You could code the custom plugin so it automatically deactivates itself after a certain date to give prior customers a grace period for downloading the plugin. You can do a lot of things, and if you’re technically minded enough to be able to develop and/or purchase a plugin, you can figure out how to tweak that code to fit your needs.

Legal Considerations

Chances are if you’re acquiring an existing plugin there will be a financial transaction taking place. Money does funny things to people.

I would highly suggest having a contract of some sort that outlines the details of the sale and what happens if anyone doesn’t hold up their end of the contract. Hopefully it doesn’t come to going to court over the transaction, but stranger things have happened. If you do end up in court, having a contract will help determine who is responsible for what.

In your contract you should, at a bare minimum, indicate:

• Who the buyer and seller are.
• How much the plugin is being purchased for.
• Specifically, what the seller is going to provide to the buyer to satisfy their end of the agreement. This might include:
  • GitHub repos, WordPress.org repo access, domain name, website content, images videos and other media, marketing materials, mailing list accounts, payment accounts, existing customer records, and anything else that might need to be transferred.
• When the buyer is expected to pay by and when the seller is expected to deliver whatever they need to provide.
• What happens in the event that one or both parties don’t hold up their end of the bargain, which jurisdiction will the parties go to court, etc.

You might want to have a lawyer write the contract for you. There are a lot of loopholes and misinterpretation that could take place without a third party writing up the contract. There may even be certain things that could void a contract in some areas so you’ll want a lawyer who is familiar with the law wherever the contract will be enforced.

Wrapping Up

There are currently over 54,000 plugins on the WordPress.org repository and countless more offered elsewhere. At some point the developers of those plugins are going to want or need to walk away from those plugins. The opportunities are out there.

My hope is that this post will help new companies grow by leveraging the success of other companies, and established companies flourish by being able to concentrate on their core offerings.