was successfully added to your cart.


Keep it, fix it, or kill it—what to do with your aged Salesforce implementation

On 4 October 2016, I took to the Dreamforce stage to deliver a talk on what I did with the 10+ year old Salesforce instance I inherited at Amazon.

Spoiler alert: I fixed it.

Since leading this session, I have been invited to speak with other Salesforce customers to share my thoughts on whether they should keep, fix, or kill their own aged Salesforce implementation and have been asked over email and LinkedIn to share my ideas of how others should go about making this decision for themselves. The most recent question I received was:

Greetings Corey, I was wondering if you may be able to share with me some ideas of where to start analyzing the instance of Salesforce to determine if a re-platform is the solution. I’m trying to determine where to begin, what metrics to gather, and reasoning for this direction. I want to be able to create a report that will resonate with decision makers. — DG.

I am happy to help, DG!

Defining keep it, fix it, and kill it

  1. Keep it: Keeping your instance means making small improvements to KLO or keep the lights on.
  2. Fix it: Fixing your instance means replatforming, either in whole or in part, to rebuild your data model, workflow, and sales process.
  3. Kill it: Killing your instance means dropping Salesforce completely and moving on — either to something else, or nothing. You do not always *need* a CRM system and things change.

Understanding technical debt
Technical debt, and the amount of which is negative, will be the single most important input into your decision-making process. Here is how you evaluate the technical debt in your own Salesforce instance:

  1. Do you have instances of field hijacking? Reuse of fields is a typical Salesforce practice; however, the active repurposing of a field across different groups is problematic — I call this field hijacking. Look for examples where a field not only has a different definition amongst teams, but also contains a different set of data per use. Too many instances of field hijacking indicates a strong propensity to replatform — a few instances can likely be fixed within your KLO program. Example: “Priority Lead”. Normally I’d expect this field to be a checkbox; however, let’s assume the field is a picklist with values 1,2,3. Field hijacking occurs when group A uses this field to track prioritization status (using 1,2,3 as prioritization options), group B uses this field to track what program this lead has been put into (using this field to track lead warming campaigns), and group C uses this field to simply track whether or not a lead has been marked as priority (just choosing option 1 to indicate priority). In this example, org-level reporting for priority is problematic as groups have begun to build their own SOPs to workaround Salesforce, not within it.
  2. Have you reached your column or workflow limits? Salesforce is highly customizable, this is why you’ve bought and deployed the platform; however, excessive customization — likely due to localization — is indicative of negative technical debt being amassed. If you have hit, or are within 90% of your object column limit (800), or workflow limit (300) — both as of 5 March 2017 — chances are high that you’ve localized too much and you’ll need to replatform rather than try to fix your instance. Why? This level of customization means that your instance has been highly localized for many disaparate processes and functions — attempting to change only one, or a handful, will simply resolve your Salesforce issue and not the underlying org data model problem.
  3. Do you have data integration jobs updating sales stages, close dates, or other fields typically set by your sales process? Steps of your sales process — for leads and opportunities — are meant to be worked by your sales team. If you have automation in place to update these steps for you, using data outside of Salesforce, it could mean that the process is no longer useful and your workflow is outdated. The use of a handful of integration to update this data is not entirely indicative of a problem; however, if multiple teams are using different data sets and building automation jobs for the same fields, you could have a scenario where your workflow in Salesforce is outdated against the current state of your business indicating a need to replatform.

Making your decision
Once you have the scope of your technical debt understood, the decision to keep, fix, or kill your Salesforce instance will now come down to two other factors: your commitment to Salesforce as a platform and the expected growth of your business over the next three years. If your commitment to Salesforce is low, and you could potentially abandon CRM altogether or move to another platform, an investment to kill your instance and rebuild is unwise. Your resources are better spent understanding your need for CRM and making its place as a business driver more well known. If your commitment level is high, you then need to look at the expected growth of your users as determined by group and role. If you are in a stable business, you can keep your current instance and resolve more of your negative technical debt through a KLO program than if you are in a growth or changing business.

Also published on Medium.

Corey Rawdon

About Corey Rawdon

Prolific stick-figure artist ideating methods and mechanisms to change the world—or at least make a small dent.


  • Darrell Gallegos says:

    Great info – Thanks for share and looking for to more!

  • Brian Bauder says:

    Your Dreamforce presentation was very insightful so thanks for the followup Corey. It’s a great point that pushing object limits may mean the data model isn’t what it should be. The number of fields and rules and the way they’re used (to your first point), should help in seeing where an org is overstuffed. I wonder how challenging it has been to get executive buy-in to replatform. Does it seem more risky than gradually drawing down technical debt through a KLO program? Thanks for the perspective!

    • Corey Rawdon says:

      Hi Brian and thanks for your comment—glad to hear that my talk was insightful!

      Regarding your question on gaining executive buy-in for a replatforming strategy, this can be thought about in a few different ways. For me at Amazon, as the CRM business owner, the decision was ultimately mine to own; however, I still published a six-pager (part of the Amazon culture) to inform my fellow senior leaders and peers of the strategy and to get their support in the project. Rather than being a request for approval, this was more of a request for support and a request to validate that my decision logic was correct. Using this method, my stakeholder teams were not only informed, but they got to choose whether to be a part of the effort or not as I do not mandate that anyone has to use Salesforce. This made buy-in implicit once they agreed to my logic and agreed to remain within the same org.

      Regarding the question of risk, I am not a fan of slow-moving projects to reduce technical debt over time as the opportunity cost is too high once you move past a certain time threshold—this will of course be different for each organization. I would much rather move quickly and fail, then quickly rebuild or roll-back rather than take a longer period of time to slowly try and make a dent in the world of tech debt while continuing to try and support new requests. Can it be done? Sure. Though I would challenge anyone considering this path to think of the opportunity cost in not moving quickly.

  • Darrell Gallegos says:

    Corey, your perspective on risk is that a true leader and visionary!!! I thoroughly believe this is the right attitude to bring to the table when attempting to evolve and being a game changer. Thanks again. Oh can you share your 6 page document? I need a place to start. HAHAHA

Leave a Reply