Description
If your Salesforce Org has been running for years, the tech debt may be adding up. If so, the question comes up whether it is better to remediate what you have or to go to a brand new Org. Allison Park, Principle & Enterprise Architect at Salesforce, explores how to make that decision and get your arms around your technical debt.
Learn more:
Transcript
Alright. We're gonna get started. In the interest of time, I'm gonna be a boring speaker and I'm just gonna use this mic right here just to make sure I'm projecting.
So let me first introduce myself, by the way. The topic here is org strategy, remediate versus new org. So just wanna make sure everyone's in the right room.
All good.
I'm Allison Park. I'm a principal enterprise architect at Salesforce.
So, prior to being at Salesforce as an employee, I was in the ecosystem for about fifteen years both as a partner and as a customer. So I like to tell folks, sat on all sides of the table.
So, and I'm gonna give you a disclaimer that, what I present today is not necessarily, based, Salesforce specific opinion.
It's Allison Park's point of view on remediate versus new org.
So, to get started here, I wanna break this down into four, three parts.
First starting with how organizations find themselves considering starting over. So as we talk about remediate versus new org, how do we end up in this situation? We're at this kind of crossroads, so to speak.
First and foremost, you probably are in an org over eight years old. Doesn't mean you have to be in an org over eight years old. You could be a lesser number of years in the org, but eight years, is the, the kind of the over under that we find, especially as Salesforce has grown in complexity and over time folks tend to create code, create processes that fit at that time, and then the business changes because business or non profits do not stand stand in one place.
That means that you're probably building up technical debt. And if you were a really, really smart org, right at the beginning you started thinking, hey, as soon as I start writing code or creating a flow or workflow or whatever it is, I'm gonna clean up after myself because something's gonna change with Salesforce with three releases a year.
Most of us are human and didn't have that kind of foresight.
The other thing is heavily customized, especially as, you know, it started to become the force dot com platform.
We stopped thinking about should I do it, and we just are like, oh, this is really cool. I can do it. We don't think about, hey, what's gonna come after that.
And then what it ends up resulting in is there's a poor user experience. So folks are like, oh my god, if I go into Salesforce, this isn't gonna be a great experience, and usually affects your adoption. So you're kinda between these two things of like, do I clean up what I have, or is that not gonna do the trick and I just start all over in a new org?
So if you can relate to some of these, quotes up here, we have hundreds of custom fields on a core object hitting governor limits. My favorite one is opportunity. If I had like the biggest offender, it would be opportunity object. It gets used as a project, it gets used as an opportunity, it gets used a lot of different ways. So that's usually the place it is.
But, the other one is, hey, we don't even know what's in those Apex codes.
We, in fact, we're not even gonna look in them, to be honest.
It's running at whatever API version it was when it was created, and we're just gonna, you know, leave it alone because it's just too too frightening.
So instead of enabling, innovation and a better user experience, Salesforce is being viewed as a legacy tool. Going back to that user experience, it was set up properly x number of years ago, and now here we are, struggling.
And the last thing is our partner came in and said, Hey, just blow it all up and start over, with a brand new org. And companies generally are like, I don't know whether or not that makes sense. And I do make a comment here about lightning. Believe it or not, we still have customers on classic.
True story.
So when we start to make this consideration between, remediating or new org, we have pros and cons on both, and they are a little bit mirror images of each other.
On the remediate side, the great thing is you stay in that one production org with your sandboxes, your dev ops, processes. It's all self contained.
It's also a lower initial investment because you're operating on your existing org, so you don't have to go out there and buy additional licenses in a new org in order to move through this process.
However, that takes a longer time to value.
So you wanna think about, does that make sense?
It's also higher risk, because as you're making changes, you are operating no matter how sophisticated your DevOps process is, you're operating on a living body, meaning people are trying to get their work done as you're trying to relieve the technical debt.
So those those are the pros and cons of remediate.
On the new side, there's a shorter time to value. Ideally, you're setting up your new org. You may be porting over some metadata, clean metadata hopefully, and, you understand how the data model needs to change, and you can get going a lot sooner, and you can treat it potentially as a little bit of a big bang or migrating users chunk at a time as it makes sense.
It's also a lower risk because you can think about the change management. You're not operating on a living body. You're moving them into a new org. The flip side being, you've got two separate environments. So when we talk about different orgs, we're literally talking about the fact that, folks need to think about, how is my DevOps process gonna work? And when I port metadata over, I don't dump it in that production environment. I'm gonna take it through the whole DevOps process again and test it out, because it's a different org.
And then there is a higher initial investment because you have, the licenses as well as that migration, not just the metadata but also the data. So when weighing these things out, these are the things that we're gonna come back to.
So how to approach the project and who to involve. And that who to involve is pretty critical, especially if most of us, like me started out as developers and you're thinking of this as a technical project.
So the first and the foremost one is what is the direction and the growth of the business or nonprofit, going in? Meaning, is it changing dramatically? You know, there are companies that they change the way that they sell. They may have gone through mergers and acquisitions, and that might be something that they need to think about. Ongoing, they may have a single org strategy. They may have evolved into a multi org strategy. Lots of things that you're thinking about from a business perspective.
And then what's that degree of negative technical debt? How bad is it?
So you're really weighing both business and technical factors.
So this is actually a summary of a Excel spreadsheet, which I'm happy to share with you. I'm gonna have my LinkedIn at the end, which basically allows you to inventory, what you have, from the perspective of first business considerations and then from technical considerations.
So the first one is, what is the age of the org? How long has it been around?
The second one is, has the business model or the vision of what we're doing as a business, has that changed changed and how significantly has that changed?
The other one is what are the business challenges? Why are you at this point to begin with?
You know, we need a better lead management process than what we have now or we need to change the data model or we're finding ourselves, you know, we thought we didn't need field service, or we put it in after, you know, before Salesforce came out with field service. Something like that, where suddenly you're saying, oh gosh, something has changed either in the technical, that makes us reconsider our business processes or business processes have changed. We've opened up a new segment or something like that.
Adoption issues. So from a business perspective, people are not wanting to go in there and that's causing a problem because, hey, you've got this great tool, for customer and even partner engagement, and they're just not going in the tool, then it's not really serving you.
Data retention requirements. So thinking about this, some organizations say, hey, I need to retain a a huge chunk of data or I need to have it there for ten years, fifteen years, whatever it is.
What happens when I move to a new org? How do I need to be thinking about that?
And and by the way, I know we're gonna have some conversations on data cloud because that does also impact maybe how you think about that.
From a technical perspective, take a look at the health assessment. So on this Excel spreadsheet, it actually has you naming some of the things of, you know, where is health an issue.
Customizations and configurations, being able to inventory that so that you can, bring it all together in one place.
What does data management and data quality look like in the current org?
Lightning, is there any classic out there?
That is a big one. I'm actually working with a customer right now who is making this decision and struggling because they have their service team in Classic.
So don't think that's in the rearview mirror for everybody.
Security and access. Do we have well defined profiles? Can we move to permission sets? You know, those kinds of things we wanna have all that inventoried, who can see what, is that actually efficient to the business process.
Integrations. And this one is key.
No matter what kind of changes you have, what all is integrated and how is it integrated?
Having that this all in one place is is super helpful, especially as you start to consider making changes.
Government limits. Are we hitting government limits? Going back to the too many fields, or we have to keep buying data storage or any of those kinds of things. Those kind of government limits are helpful.
AppExchange packages.
Over time, folks say, oh, it's not gonna hurt anything. I'm gonna get this neat, AppExchange package. And I put it in, and I might even have some code that's connected to it, and then I stop using whatever it is, and I forget about it, and it's just sitting out there being technical debt.
Reports and dashboards. This is actually one of the easier ones. You still wanna inventory it, but it's cleaning up reports and dashboards. If folks haven't used it, considering, hey, how do I move it off so that I don't have that in the way, so when somebody's looking for a report.
One good rule of thumb, by the way, if you're cleaning up reports and dashboards, is think about it in terms of two years or even eighteen months, because those annual reports that get run, a lot of folks kinda forget about that part. It makes sure that you don't clean up something that is still needed.
And, lastly is governance and release management, calling this out to make sure both that we're doing it in keeping with that. But if we find that this is maybe lighter, even if we move to a new org, we may end up in the same place in a number of years. So making sure we call this out and we think about it, is super important.
So who to involve as you're having this evaluation?
The company's, Salesforce leads, Salesforce admins, it's totally obvious that you wanna include those folks because we're talking about Salesforce here.
Line of business leaders. Now this is crucial too because you're gonna be changing Salesforce. So those lines of business leaders that are directly affected by the use or non use of Salesforce should be at the table.
I find very often when I talk with customers and also from my own experience, many times the business is like, I don't care, you know, just take care of it, kind of thing. But you really wanna pull them in because as you're making this decision, it's gonna directly affect their experience in Salesforce so they have the right to have someone at the table and understand why they're there and what their role is.
It's great if you also involve, like, Salesforce enterprise architect like myself, solution engineers, and account executives.
If you don't have access to these folks, at minimum, you should have access to your account executive.
While I've heard folks say that, you know, hey, I don't have a great relationship with my account executive, they do serve a purpose beyond just selling new stuff, can connect you with resources as you're going through this, so please do think about involving them.
And the last one is partners.
While your team may be excellent at what they do, it's probably not something they do every day as large scale remediation or moving to a new org. So having a partner involved as you go through this process helps educate that partner and understand as you're making those decisions, you know, what kind of support you can expect from them and money. So all good things to think about.
So lastly, I just wanna give you some examples as we walk through this.
We're doing, I think, pretty well on time, great on time. And I will have chance for questions and answers. That's my favorite part, by the way.
So let's talk about some sample orgs. I've got two, where one is a new org was made a decision of, and then the next one is gonna be that they made the decision to remediate. And then I've got actually some, two coming at the end, from past Dreamforces so you can actually hear it from the customer perspective.
So as we start thinking about it, I was just going through a long list of things so you can inventory what you have. When this customer did this, they went through this, and this is some of the highlights. So when you look at it, when we look at the age of instance, it's greater than ten years old, or about ten years old.
We put a red indicator because that's usually kinda on that spectrum of I probably wanna go to a new org. I've got a legend in the lower right hand side, depending on which screen you're looking at.
Are the implemented processes mapped to the new business model? So in this case, no. The specific example that they called out was a lead conversion.
The way it was working was it was actually creating multiple accounts from one lead.
The reason being is, if we look a little bit further down here at the logical data, model, the current data model was designed to support processes in product.
Oh, no. I'm sorry. It was, basically the idea was that their business model had changed, so that is what was creating that issue.
The adoption is there's frequency, meaning people are logging in, but they're not really doing a lot with it. They're getting basically what they need, so poor usage, in the field.
And they were using another tool for opportunity management because it was a better experience.
Certainly when you have Salesforce, when we first started, Salesforce, you could just like lay down a credit card and you were off to the races, creating shadow IT.
Not so much so anymore, but shadow IT is still a very real thing. So you can have that happen when folks don't believe in the platform you have in front of them.
So that was the case, as well as classic.
How is the fidelity of data when they align to the new vision?
There is low trust in the quality of data that's in Salesforce.
They don't believe it. They can point out examples where there are multiple accounts for a single customer and usage data is not current.
Logical data model. The current data model has been designed to support processes and product. It has some limitations which account, impact the account quality of data. So, they don't believe the data and the data is not in great shape. And then lastly, that org health model, when we're looking at it and we're comparing it to peers, they have a lot more than twice the number of the peer groups. So in this case, because we were pretty much all either deep orange or red, the decision was made to move to a new org.
So they said, hey, we want that shorter time to value. They also said because of that data model change where their leads was creating multiple accounts, they said we really need to re engineer the whole thing, and that's more safely done in a new org.
So now if we look at, another example, this one actually, the age was eighteen years.
But the direction and the growth of the business was really just to scale, that they were still using that same model.
The original vision has changed to more cloud based selling, but the customers are largely the same. So the way they're going to market is a little bit different, but it still works with the concurrent order in.
Are there implemented business processes mapped to the new business model? Yes. Actually, lead and opportunity, opportunity to quote, are generally set up for what they need to do.
And then, as we look at org health, the adoption is pretty good, but there is the indicators that they have technical debt.
They have not exacted lightning in this case, and there's a lot of duplicate records, which is an ongoing issue for most orgs.
But the adoption for the platform is very good. Actually, most of them are on desktop. There's low mobile and they're not on lightning, but we're still in the yellow area.
How's the fidelity of trust? It's actually pretty high for the data.
It's pretty complete and accurate.
And, while there are duplicates, they do have a process for continuing to improve that using, Dun and Bradstreet at the time.
And then lastly, the data model, the two level account hierarchy is working fine and they don't anticipate any changes. So as a result, remediation is fine. The biggest thing I wanna call out here is the age of instance by itself isn't enough of an indicator to say what I should do. So really going back to inventorying everything and having, everything all in one place and making that evaluation is super important.
So there, when they went to that remediate, they could use that single production environment and, lower that initial investment.
So these are two, there's a link at the bottom, and again, using LinkedIn, I'm happy to share these these slides with you, was Amazon.
They actually ended up deciding to start with a new org.
They really saw that, and I'll just kinda, abbreviate this for you. As they were looking at this, they really wanted to do things differently than they had before and really reinvent it. So from a business perspective, they were really taking a fresh look. So going into a new org make a made a lot of sense.
It was a way to really kinda quite literally start over. And, so they started thinking too about how they approached it, thinking in the long term and doing it right from the beginning, and then managing it ongoing, and then doing it in minimal viable products, so iterative releases of capabilities into that new org. So they're not doing big bang. They're doing a much more agile approach.
And it took them about eleven months for the whole project. Now, this is Amazon. They had a huge number of resources working at it.
But nonetheless, I think seeing someone else and comparing to somebody else, even if it's Amazon, can kinda give you some good ideas as far as what to remediate in process, or in place.
They had an older org, they had about seven thousand users, but it was very heavily customized.
When they went through this process, I love this before and after, the number of profiles and everything reduced significantly. And especially look at price books, went from eighty five to one. So really putting on that discipline of saying, what can I compress and how that shows up? And you can imagine, you know, just this clean up, whether you go to a new org or whether you remediate, reducing that amount of technical debt is gonna make you move a lot faster in what you do. It's gonna make that user experience better, and it's just gonna be easier to adapt new changes going forward.
So I think this is everything. Again, this is my LinkedIn, so please, you know, send me a note if you wanna have that excel form to help you, inventory everything.
I actually call it a template, meaning that you're gonna add your own things to say this is significant about our org, we wanna include it in the categories. The, the business side is very short and then the, technical side is very long, as you might expect. So, we have time for questions and answers.
Anyone have any questions? Yes, in the back.
Yes.
So in many cases, let's say, you were asking and I'm gonna repeat your question for the folks, since we don't have I don't have a mic here. So basically you are looking at the same thing, remediate versus new org, and you talked to your account executive and they said, hey, I can connect you with an architect or solution as engineer. What you can expect from them, like myself, and I'm part of the presales team, is that we will bring this expertise and resources to bear. It's not gonna be able to do it for you, but rather things like this to help you make that decision.
So it's also, generally speaking, no cost. I mean, you can ask that. Is there any cost to this? Are you suggesting I'm, you know, upselling? But likelihood is no. They want to bring the technical resources to help you sort it out in your mind.
Does that help?
Okay, sure. Yes.
Yeah. Actually, it's it's great that you brought that up. There is another conversation, which is single versus multi org and making that decision.
So when you're making this decision, that might be a good time to also, although it complicates it, add that on. Is say, does a single versus multi org solution make more sense?
And if so, then as I am considering a remediate or new org, that may have an impact. I actually have a customer in South America who's going through exactly that same thing. They're doing both, new versus remediate and single versus multi org at the exact same time.
So thinking first and fore so this is from my approach, and I have another one on single versus multi org out there, is thinking about that first and foremost. What's the ideal world look like from a single versus multi org?
DataCloud has some super exciting things about making multi org even easier than it used to be, but thinking about what's right for your business. And, without giving you that presentation as well, I would say that that's your first, you know, conversation and decision point if it's single versus multi org, and then get into the new versus remediate. Because if it's multi org, maybe you remediate one and the new org becomes something else.
Maybe you say tech debt's terrible between multiple orgs, but we wanna stay in multiple orgs, so we've gotta set up multiple orgs, and maybe we wanna do that, you know, time at separate times so we're not trying to do multi to multi.
So point being is make that single versus multi org decision first, before you get too deep down the remediate versus new org decision.
By the way, you're never in a wrong place for deciding to remediate. You're never gonna regret that.
Your your question is, is data migration a big driver at determining whether you remediate versus new org?
Or the data model, whether it's right now or needs to be changed.
Yes, that can be a huge driver. It it's not the only consideration, but it can be a very big, driver as far as how I do it. Because obviously if you're remediating in place, you have to make massive data changes that you're operating on an existing body, that org, can really impact, you know, how hard or easy it's going to be.
So it it depends, you know, because if it's if it's in, you know, we're gonna go from custom to standard, I may be able to make that migration more easily in one org, but maybe not.
But it's definitely a consideration. Yes.
Yeah. So things like the optimizer report and the health, score, those are things right in your org that you should do, you know, full stop.
Depending on what you have access to, you know, certainly having good dev ops tools helps.
There are If it's around data, there there are sets of tools out there. AppExchange is the first place I would go, and assess. I don't have any specific recommendations, but yes, depending on what you're trying to get your arms around, there's a there's a number out there.
I didn't have any specific recommendations, I apologize, but do the basics. Everybody should be at least do the basics. And then as you start to see that, especially the optimizer report, what are the things that are in the big piece, figure out what you can remediate yourself. When I I wanna go back to what I said about starting with remediation.
If you decide in the end, hey, I need to go to a new org, but you've cleaned things up, it's a lot easier to move when you're not moving the garbage.
So starting small, there's never a problem with starting small, and I would suggest it's a good place to start.
Any other questions?
Yes.
Yep. From the examples that I shared, what was the impact to the user experience? I think two things. One, that's why you want the business in the conversation, because you don't wanna be like, surprise, we got a new org, or surprise, we're going through a remediation process or anything like that.
You definitely wanna be communicating, good change management process anyway, over communicate so that they know what change is coming, what happens after the fact, when they can expect it, things like that. Because even if they're really frustrated where they're at, knowing, hey, this is gonna change. This is when you're gonna be trained on the new process. This is what to expect.
Cleaning things up, whether you're remediating, whether you're going to a new org, will be welcomed by users as long as you don't surprise them.
Because it's gonna make their jobs better. Fewer clicks, hopefully.
Less data entry, hopefully. All those kinds of good things.
And ideally, you should be having user adoption be one of your metrics to prove your ROI for whatever changes you made.
Does Does that make sense? Good.
Alright.
I think we have a few more minutes if anyone else has any other questions.
Yes.
Yes.
Mhmm. Correct?
Doing this process. Yeah. The the question was, for those listening at home, not or comment, I should say, is about, data cloud and how helpful it can be. I think data cloud's opened us, opened our eyes into different ways to architect, and Data Cloud can help you through this process. Do know that Data Cloud can be connected to multiple orgs, So if you're going to a new org, you can connect it to both.
But, I think that's probably a whole another conversation on data cloud.
So it's right after break. We get a break and then come back for Ryan's.
Okay, great.
And Ryan's will also be online, so if you're listening at home, you can tune in.
All right, good. Thank you, everyone. Thanks for hanging in there.
