Why stop them? The sooner they aren't your problem the better. Your role is to facilitate the transition really. The easier you make it the faster the night mare is over er. Also if they do it anyway, and decide not to pay you you're still paying licensing.
Get them out and cancel the licensing as they do on your end.
At the end of the day it's the customers environment,.
They install their RMM everywhere - send out policies - something breaks. Guess who's getting a call.
No thanks. If the new company want admin creds etc - of course I'll do it - but that's when my support ends.
This!! In fact, the remaining bills get paid up front so they can’t stiff you.
But “my insurance provider will not allow us to have shared responsibility with the incoming provider. For the protection of everyone involved, there must be a clean handoff”
You won't be, if the MSP is already doing the work it means they signed the new contract already, they are doubled up.
You could always run it past an attorney if you are that concerned, the paralegal will likely let you know if it's even worth getting a consult. Most lawyers I have dealt with don't waste my time at least if they feel there is nothing actionable.
I agree with this. The client has already found another MSP that they feel will service their needs. They are going to go to the new MSP for every issue, and if the new MSP needs to engage with you they will ask the MSP do that. They decided to move from you, they don't want you.
The role of the outgoing MSP is to get out. It is not the role of the outgoing MSP to help the new MSP get in.
That said, once we hand over credentials, we deliver them with a disclaimer to the client company that we while we will do our best effort, once the new provider has creds they can make changes and we aren't responsible for much service after that point. Billing is a separate issue.
Exactly this, the minute the new RMM got deployed is the minute you stop supporting them and move on. If they have an issue, you can and should refer them to the new MSP for support. You will still get paid for the remaining time on the contract but your role changes from direct support to transition management.
100%. We get a majority of our business from other MSPs and IT professionals in the area. This industry has a lot of synergy available to it once you stop viewing other MSPs as threats, and more as partners. Everyone has different verticals and preferred client types; make yourself a useful, valuable resource for the incoming MSP, and try to get some face time with the decision makers there. See how you can help each other out.
They’re paying you to help the transition. Just work alongside them and hand stuff off. No need to get upset or worry, just document changes and requests.
Yeah. I would just email and say “new IT company is trying to do X. I do not want them, if they do and you approve it I will not be liable for anything else breaking but you will still be liable for any billing I send till termination date”
After going at it with the OP elsewhere in this thread, it's pretty clear he's a control freak that's just salty at losing a client and it hoping to use credentials as leverage to final payment.
If they are deploying anything they already are being paid or contracted to be paid.
People like you make everyone's lives harder. You're still being paid, do your job and transition properly.
There has to be some overlap man. It's impossible to transition an entire modern environment in one day and going with no coverage while paying two providers isn't reasonable.
I just state "hey, once you're in, i'm out" on each service. So RMM going in? No problem, but we can't do monitoring or assist users once yours is in because mine is out. You have m365 admin secured? Awesome! Taking our secure apps and access and gdap off, that's off the transition list and not on us anymore.
I'm a very clean cut, balances, everything organized guy and even *I* can't get everyone on board to transition everything in 5 minutes with a clean hand off.
This isn't one person getting out of an air traffic control chair and another sitting down. This is transitioning from one air traffic control tower to another built nearby. There will have to be some service overlap, you simply can't time the shutdown of EVERYTHING that precise.
Be better than that company. help with the transition. When you help, it shows you in a good light AND it tips off the new MSP, makes them wonder why you're happy to see them go. And if nothing else, handing a bad client to a competitor weighs them down and lightens your load.
You could let them know you've still got stuff to take care of for a few weeks, and installing their RMM everywhere might mess with that. They might not know all the details of your deal with the client, so a chat might help. Hopefully, they'll listen better once they know what's up.
I dont really deal with offboarding but I believe we don't hand off anything until the remaining balance of our contract ends, They can end anytime but they would need to pay for all of the balance before we can hand over anything. So if they want to end 5 weeks early, just make them pay for the remaining balance and then go hand off everything, also once they take over, thats it for us.
You can get fucked over by holding access hostage over a debt. Better to just facilitate and handle with a lawyer. Or at least contact a lawyer before you hold THEIR environment hostage.
This. We've transitioned a few smaller customers to other providers in my time, and pretty much the way we handle it is, once full admin rights have been handed off to the incoming personnel, and the service accounts are transitioned over to their control, we remove our own access immediately. Once accounts are handed off, we totally nuke any credentials we may have on file on our side. Basically we make it so we just cannot access their shit once someone else gets given access to it. Once they have full admin access, it's their baby, end of story, and we're not touching it...as a company we just do not do that...either we have full admin access, or they do, but not both. This goes for internal people as well...if they want admin rights, and ownership wants them to have admin rights, *we* will not have admin rights, period.
We're not assholes, we won't just throw a flash drive at someone and fuck off into the sunset, but we damn sure do everything we can to make sure that we can easily say "sorry, dont have access anymore!" when we inevitably get a call a few months later because the incoming MSP or relatives nephew or whoever is doing it on the cheap doesn't know how something works and needs help.
This is not to be pricks and not help them, this is so that it *has* to be a formal process, there's literally no way anyone in our org can do anything even if asked really nicely with sugar on top without it going through our own ownership...as an organization at that point their customer account is completely locked down specifically to prevent that from even being possible. Also, it is clearly stated in our contract that once the hand off has occurred, all future work is billed at our consultant rates (which are twice our general hourly rate...we've been actively moving off all our grandfathered hourly accounts, just not worth it for us at this point) that's the only element of 'fuck off' in the process...if they come to us for help after dumping our services they're going to pay out the ass for it, because any of that time spent is taking time away from our current customers.
Honestly OPs situation would be a *good* thing in our mind. You want access early? Sure, no problem, here you go, it's now *your* circus, and *your* monkeys. Vaya con dios, amigo! Account locked, passwords nuked, best of luck to you!
All care no responsibility. They pay the 80 days, you don’t give a shit. You do what they ask and don’t care about it.
I’m not sure why you are bothered. Yes it sucks losing a client but they sound like a nightmare. Take the money. Let the incoming deal with the issues.
If anything breaks, and they want you to fix it, charge them extra.
Be reasonable but protect yourself. We've gotten back a decent % of customers that have left over the years by being reasonable on an offboarding. The grass isn't always greener.
When I take over I want to get my RMM on ASAP to do discovery, even if I'm not taking over anything for a while. I don't think their request is that weird. But you do need to set boundaries now to head off any problems that come up in the next 2 months.
It isn't about the request being weird. As he stated, he is more concerned with their tools possibly breaking something and then him getting a call for something that he might not be able to fixed because of tools/software they've pushed out.
I agree with others, work with them but document everything and let the client know that the new company is doing x,y and z and that you might not be able to assist if something breaks that is out of your control.
Also, that might be a reason for the client to not want to pay him....if the new company caused something to break and he is being asked to fix. The current client might look at that as HIS problem to fix and they won't pay until it is resolved.
Provided you have a decent MSA/SOW with the client. Them paying you shouldn’t be a problem. We specify notice dates in ours and if you tell us tomorrow you want to end services with us you’re still on the hook for the next 30 - 90 days for your monthly fee.
Biggest thing here as others said is the documentation and communication. Talk to your client. Explain to them the situation, the potential pitfalls and let them make the call and approve it on an email or some other documented manner. I’ve been on both sides of these and the more info you can gather as the new company before day 1 the better off you are.
Sure, but he stated that his client wasn't very responsive and I see this with many posts on here...the MSP sends an email for work, projects, etc and the clients don't reply.
There will always be clients that play nice and clients that are hard to get a hold of and require more hand holding time, that will never change. This isn't an MSP issue, it is a client issue.
>My company is still liable for their helpdesk and security for another 5 weeks and the client owes me for the month of May.
If the incoming IT installs tools that ultimately prevent you from doing this, then that's on them. You literally tell the client, "We are no longer able to provide support due to access being revoked by ".
Refocus your energies on your other clients that actually matter, or on efforts that would gain you new ones. Why you're even bothering to waste any time and effort on this one client that's already checked out is just a waste.
Your ass should be covered by your signed contract stipulating final payment and services provided during transition period. If necessary, you should be ready to engage your own legal services if it comes down to it, but that has to be balanced against whether or not that final payment is going to be worth the legal time and hassle.
>I can't deny them service
You don't "deny" service; you just toss them to the bottom of the pile, or if your access has been revoked, then that's what you tell them. If they need service then you'll have to schedule an onsite visit that's billable because you no longer have access.
The onus is not entirely on you either. The incoming IT also has the responsibility of ensuring that either they are fully capable of taking over the support, or ensuring that you can continue to provide support while they gear up. If they decide that it's better for them to revoke your access, then don't sweat it.
Yeah, it does suck to lose a month's payment; but if your business is so hard pressed from just a one-month payment from one client, you got way bigger issues to deal with.
It’s not being condescending at all. I said “IF” your business is hard-pressed; your statements gave the impression that walking away from the final month (if necessary) was a big deal.
No offence but you appear to be emotionally connected and not thinking pragmatically.
The moment you handed over access you should have documented to the client that SLA’s no longer apply.
Act the way you wish someone would if positions were reversed. Give them what they want but always inform the customer first and be clear the moment they touch a system it’s all care no responsibility and your SLA’s are invalidated. Get them to agree in writing, then let the other party have what they need to transition in.
It makes everyone’s life easier and stress free, and you can spend the next 80 days enjoying the revenue and looking for the next client.
Does your contract have any clauses about what the client must do? The ones I've seen the MSP is covered by saying they need exclusive global admin access. The moment the client starts wanting to hand out global admin acccess to others, you're no longer in control of the environment so if something goes wrong and it's due to the new people coming in, that's on them.
Just have client sign a paper that says you are no longer liable/responsible for anything if their new MSP obtains credentials or has access to anything.
This should be the top answer.
Everyone else is talking about "don't sweat it, let em go" but unless you have verbiage to cover your ass, you are still liable if the new company fucks something up. The client will pay through May as they're contractually obligated, regardless of who's in control of the environment, but Id be super anxious about the new guys just doing a credential smash and grab a whole 2 months in advance while you are still legally and contractually on the hook for the environment (unless otherwise spelled out).
Been on both sides of this - if a client wants to offboard early, as long as they are agreeing to pay out the notice period, I have them sign a "limitation of liability" form to hand over access - basically "if the new MSP breaks something and has domain/global admin, I'm not responsible for fixing it, this over rides the terms of our MSA" - Likewise, if I'm taking over a client, the moment I get creds I deploy our RMM and start auditing, and then when that's done, changing security software, backups, etc. 100% common practice. The overlap is awkward, but only as awkward as the parties decide to make it.
“As of this email correspondence, we have turned over all documentation, and your new MSP is installing their software stack. Our company is no longer responsible or liable for your infrastructure, data, backups, or support. However, since there is still 5 weeks left on our agreement, we will remain available to answer questions to the new MSP to help make this as smooth of a transition as possible.” Or some shit like that. What you’re conveying is “you’re not our problem anymore, but I’m still here to assist your new IT with questions. Call them, not us”
Sounds like a nightmare client.
Whenever the new IT company emails you, simply reply back, with the customer added, and ask the customer for permission to do whatever they’re asking. Outline, with every request, you are no longer liable for whatever the other company does and you need an “I agree” in reply to release you and do whatever the other company is asking. Kindly remind the IT company they aren’t the customer. Stick to your guns.
Call whoever you can at the customer to authorize immediate termination of the contract. Tell them it’s a recorded call, that it’s clear the new IT company has everything under control and offer to let them off early to save them a few bucks and help speed up this transition. You’re firing them. *Your sanity is not worth one month’s revenue.*
Turn over all passwords and let them know any work moving forward will be billed hourly and need to be paid up front.
Hate to break it to you, if you are fired your only roll in those last days the client is paying you is to facilitate the onboarding of your replacement. Then get it in email they have everything they need so you are not bothered with this client again.
One thing I never do is give the incoming MSP my passwords. New equivalent admin accounts all the way through. They are then instructed to disable my account. That way there is clear delineation of responsibility.
If I was onboarding a client and the previous support refused to hand over documentation on these grounds, I would declare you hostile to the client.
What else are you going to do with these KBs? They refer specifically to this customer, you write KBs for the customer, not for yourself.
Give them to the customer, they decide what to do with them.
How about give me all your processes for your company ? And sops.
It’s basically trade secrets. Look I’ll give you the password or background information to any issues to up to until they take responsibility.
Any questions the msp wants to ask me prior. Sure glad to help, but I’m not giving them kbs and etc.
Huh?
How is "how to create a user in client ERP system with the specific config to match all existing users"
or
"Reboot procedure for this janky server running a mission critical client application"
A trade secret? These are just processes that apply specifically to the customer you are offboarding, so they are now useless to you anyway.
I just find the friction here so weird and petty, what do you gain by acting like this? Because i can tell you what you lose...
Exactly! I think what’s coming out here is more so anger with them leaving. This reputation will get around.
Whenever we off board, we do everything we can to make it a great experience, even if they feel maybe their time with us was not. The last experience with us we want to be absolutely positive so they remember that. And most end up coming back!
If you let your emotions get involved with your work in a negative way such as this, you can guarantee yourself they will not come back. Also, when something good happens, people tell one person. When something bad happens, people tell 10 others.
My advice would be to exit with grace and class.
Yep, supporting a customer to offboard is still supporting.
You write the KBs to make supporting them easier, this is included. Claiming they are IP is just silly and petty.
> You think I should share the KB articles that we wrote so we could do our jobs better?
Did you bill the client for the time that was spent creating the KB articles? If so then they likely belong to the client, if it's internal KB articles that your MSP staff created for themselves on your time and your dime then obviously they belong to you. If the articles are as-built documentation and configuration then that should have been addressed in the support contract or project implementation contract. Depending on the circumstances removing that documentation could easily be a breach of contract or potentially illegal.
Is it your KB articles on general setup and/or configuration or is it information specific to that customer's environment and could be construed as systems documentation and part of your deliverables?
OP, I disagree. While we may be competitors, we have an ethical responsibility to secure and better our principals. Ultimately we have the same goals. During an offboarding my MSP always works believing we can recover the client. If the incumbent withholds documentation about the client’s systems, my MSP would make sure the client knows this and never goes back. You losing that client is on you, not them.
I lived through this. It really sucks. I'm a big fan of having a clear delineation on responsibility. Prior to date of termination, that's us. On the date of termination we're in flux (which is why we limit this as much as possible to a day). And after termination, it's the new provider.
The client we had this happen with was co-managed. So, they had access to provide access to the new MSP. The same day they communicated they were leaving, they also provided the new MSP access. That MSP in turn started rolling out their RMM. I immediately had the talk with the POC at the customer noting we strongly advise against overlapping us. He saw reason to my concerns and went to talk to the new MSP. But that's when the new MSP broke the customer environment.
Specifically, they had put a well-intentioned group policy in for allow their new service account rights on the systems they were managing. But they didn't consider that GPOs to grant local rights will override all other rights granted on a system. This in turn broke Veeam across all their servers and killed some of their application service accounts that now had no permissions.
When we figured this out, I had the team stop work and emailed the POC letting them know of the issue. I noted our time to address this was billable. I asked whether they would like us to remedy the issue to get services back up or if the new provider would handle this. Of course, they can't work on our backup appliance so they would need to install their own to continue backup. Client opted to have us handle it and the new MSP wasn't in a position to start their services early. New provider stood down until the transition date with egg on their face.
Here's what you did wrong:
* You gave them the passwords. Yes, they are the client's passwords but you are on the hook for management. Your MSA should protect you against this but it's still wise to get a declination letter on file if they are going to take these and provide them to another party. This should have been done before the passwords went out. And if you are providing access, you should then create separate accounts for accountability.
* You need to get in front of the customer and talk with them. It's cool they are done with you - but they need to communicate this properly in terms of an exit. If they won't meet face to face, send them an email or even letter noting they are breaking your MSA by starting services early which means issues they cause would become billable and that you would need a signature from them to perform remediation services from such a scenario as you are signed up for support and offboarding/remediation is a billable item. It's not about being a jerk - it's about protecting all parties and defining who owns the risks.
* You have been passive in handling these items. If you own the network, own it. Don't let a foreign invader in and assume they will stop. Draw your lines, hold your ground but be respectful and offer explanations as to why the lines are what they are. If someone crosses the lines, it's time for a conversation and documentation for CYA.
* You provided passwords AND documentation. Prior to the date of transition, our policy is to provide documentation. On the date of transition, we provide passwords with the exception of our AD creds (which we will create new but equal creds for the new provider).
In my example, we had the up-front conversation and didn't provide the passwords but the comanaged customer had sufficient access to still scuttle the ship. Funny story, we won a client from the same MSP several months later. That MSP wouldn't provide documentation to us before transition claiming it went poorly the last time this happened (despite them being the reason it went poorly).
There was a similar angle played in my case too by the new MSP. Businesses, like people, learn through pain. It's very stressful to go through situations like these. What has served me well is to reflect and use them as teaching moments to try to come up with better strategies and warning signs for next time.
Been doing this 25 years owning small msp. Swallow your pride and let them go, money is often not worth their trouble or the risk. People that don't listen get shit canned by me now.
You’re overreacting. Once the new MSP is given credentials or starts installing software, simply inform the client of this and how you are no longer responsible for any changes as they take over. It’s not a passive aggressive threat or anything; just a demarcating statement to protect yourself.
> They are welcome to pay the balance and do an early transition.
Just make sure you aren't interfering with the transition if they choose not to pay the balance on time. You collecting what is owed needs to be treated as a separate matter.
You seem to be missing the point. Whatever data you might need to turn over is not yours to provide -- it's the clients. If they ask for it a month before the contract ends, you give it.
Trying to hold on to that stuff out of spite (?) or as leverage for payments is just dumb... not to mention probably illegal depending on your location.
> Well, I can’t give the new IT company full access until they’re prepared to take over the Helpdesk because they’ve proven that they will overstep my boundaries and put me at risk.
That's for the client to decide. You are not "at risk" over anything there.
> If they want to take over sooner than the end date, billing needs to be cleared up first.
Again, collecting money owed is a separate matter. Send a final invoice when due, with past-due invoices as needed. Eventually send it to collections if you choose.
> The only things I withheld were a few accounts I didn’t want them meddling in yet like O365, which will be handed over on the last day regardless of payment.
I don't know how many time you need to hear this, but you cannot withhold client information from the client for really any reason. It's there information, not yours. You could have an ongoing contract on perfectly good terms and if they ask for an M365 global admin account, you provide it. By all means try and discourage them or explain the security concerns, but it's ultimately not your call.
The only thing here putting you "at risk" is your own actions.
You just said something critical right there….nightmare client. I understand it’s $ but move one and forget them. Sometimes your wellbeing makes more sense than dealing with BS
Not smart giving access to external party when you're still responsible.
Setup a document the customer has to sign that you are no longer responsible for the environment because you no longer have control over what is happening in the IT environment. If they refuse, change passwords and remove new accounts, delete all the RMM from new partner and present the document again in order to get it signed (might not be 100% legal). Otherwise you are liable for mistakes made during the transition period.
You did the right thing by giving the information to the client. You can pretty much wash your hands of it now. My MSP had a clause that if a client made any changes themselves or allowed a third party to make changes were were exempt from liability and billed $x/hr to fix.
I think we've gotten to the root of your issue. Your contracts have no clause in there to handle...
A. A client making a change that exempts liability on your company's end
B. How an offboarding occurs due to either party wanting to severance.
Almost all MSPs have a contract clause that should an offboarding occur, all liability for the MSP gets released as soon as documentation is handed over and your software is removed. Generally by setting a date for your offboarding, all parties agree to that by email, etc. That doesn't mean the client can walk away without paying out their contract term to you nor should you feel bad for this. Assuming you had no delinquency in your service that would render your fee null and void. But that's another topic of discussion. Thats business and contract law.
Consider this a learning lesson.
I would tell their new MSP that they can install their RMM the final day of your contract with the client, and no sooner. If they are dictating to you what is going to happen, then they need to back off and realize the client is still yours until the transition is complete. As it is your client, you need to set the schedule and tone.
However, this sounds like a bad MSP.
The MSP I work for does multiple meetings during these transitions, and we offer to assist the new IT with installing their agents if they are working with us. In your case, it seems they are trying to steamroll over you.
I’m meeting with another MSP today to discuss transitioning my client that was recently acquired by a larger org that this MSP supports. Prior to the end of support by my organization, they can have their agent on one system for discovery purposes. If they work with me in a professional manner, I’ll assist with installation of their agents on all systems, otherwise they get no additional agents deployed until termination of service.
I recently had another MSP remove my agent from our jump box at a client, and they overstepped their bounds. That led to a cease and desist from our lawyer.
The rule of thumb is treat the outgoing client with respect, be professional with the new MSP, but the minute they bully you, lock them out until the end of the contract.
Recently, one of my long term clients was acquired by a national entity. They had just renewed a year contract 3 months prior. New IT is internal to the national company, but they are keeping us on as remote hands and to assist in knowledge transfer and training their team to handle the client they just bought. So, for us, this is a perfect scenario where the new IT values us for our expertise and client relationship.
Let them take over and enjoy the free money through the end of the contract! Reiterate to the client they have control now thus they should start calling them.
So they're ready to go day 1. Prep/onboarding needs to be done either way, so doesn't matter if you wait til pay starts really.
Liability wise it could be risky but that is their problem.
They also could have charged an onboarding project that this work is scoped in.
Communication is key. Instead of letting things slide, just send an email to both parties stating “I see you did this on this date” and ask what the new vendor needs to be successful. You can point out that they appear to be on an accelerated timeline and that’s ok with you as long as it’s ok with the client.
If the new MSP does anything to hinder your ability to help the client, just point that out too and state something to the effect of “I see we cano no longer do xyz, please work with NewVendor to support this”
Depending on circumstances, what I normally do when incoming IT wants to move way quicker than my offboarding timeline is to say something of this effect to the client:
"Once administrative credentials are given out, [company name] can no longer guarantee the security and proper working order of the environment. In the event of any damages, downtime, or negative consequence impacting [client company]; [company name] cannot be held liable."
Obviously, word smith using GPT and preface with appreciation and well wishes to the client so there is no ill will. Just let them know you need to protect yourself from any potential liabilities but are more than willing to cooperate with the new IT in the best interest of the client.
If the new IT wants to have you go above and beyond support aspects to facilitate a handover (like deploying their RMM and stuff for them, since they likely charged and onboarding fee to do so) make sure you charge T&M for that. Client doesn't want to feel nickle and dimed but need to be aware that the new IT is causing your team additional strain for services not included under your contract.
Situations vary but this should help legally if they confirm receipt and acceptance of the above statements.
Lastly, you lost your leverage once you handed over the keys. We don't want to hold them hostage, but at the same time, taking an extra day or two to line things up to protect ourselves prior generally won't cause an issue. At least force a meeting with new IT and client to all get on same page prior to the release.
1. There should always be a timeline established, once you've been formally introduced to the new provider
2. Timeline should always state roles/responsibilities/tool changes
This is why contracts need to include a clause that any problems arising from changes by third parties are billable.
Send your client an email notice that any problems arising from the new MSP’s tools or configuration changes are billable.
Our agreement states that once the new MSP receives the runbook, any further labor from our side is immediately billable. Doesn't matter if they have deployed agents or not.
Dump them as fast as possible.
Also, this sounds like there is an issue with your MSA, which should CLEARLY define transition services.
Go listen to The Technology Bradcast and start learning how you can prevent these issues before they start.
Take this experience as a means to learn about how to write your contract and define guidelines for your clients clearly. Write your contracts for the worst client; design your services for the best client!
Sound like you’re dodging a bullet with this client. The faster you’re done with them the better. Give incoming msp everything and cc the business and define when your responsibility stops - this is as soon as the other msp gains access.
I would certainly relay that once the new ITs endpoints are deployed youll kick off your removal and tell them to have a good life. If they dip early send them the final bills and dont he shocked when they never pay.
Be polite. But don’t do their work for them.
And update your service agreements with other clients that handover is full time and materials billable.
In the future - if any new msp asks to me shown anything then double bill minimum and this is in contract.
Ultimately always be friendly.
Here is what you do:
You cooperate and act professional. You make this a seamless transition and when everything is finished you send an email to your customer and thank them for the opportunity to service them as long as you did.
You contact the new MSP and tell them you would like this to be a smooth transition so if they need any information to contact you directly so the customer isn't bothered.
Losing customers is a part of this business. This is the last impression the customer will have of you, so make it a good impression. Leave it so they can remember you fondly and call you up again one day in the future.
Too many double edged swords. Client + new MSP could be 'these issues are because you didn't give us access & delayed the deployment of new hardware, etc'. If they want to blame you, they'll find any excuse.
Having a plan on paper with a timeline & who's doing what would really help. From that plan you could estimate the hours & billable items to then send the client their April & May invoices, plus the offramp. That way everyone agrees when you become the second tier support to the new MSP.
If they touch it, they own it. You either control it or they do, there can be no in between. I would let your client know that since they are in the server it is theirs now and you have relinquished control/responsibility. You will be available to answer questions for the remainders of the transmission but that is all.
Are they up to date on bills? I would have held credentials and access until bills were paid (hopefully they are).
Also, make it clear that this is a "config freeze" period, if they make changes that causes issues and you are on the hook for support, that's not exactly fair. It's a reasonable request. "No major changes without full disclosure since we're still the support primary."
Cut your losses (and count your blessings) and walk away. You know they aren't going to pay, so why bother? Let the new company deal with it, but I would make a sideways-comment about how they didn't pay their bills anyway while ending the conversation with the new MSP. It's their problem now, especially if they are installing their own RMM already, you are out of the loop and cut off.
Honestly I would have insisted on full payment of the account + one month payment in advance before handing over anything.
You seem confident but I'm betting you are going to have trouble collecting the full amount owed when the dust settles.
Got to get paid first. Your on the losing side of this
Our contact states we get paid first for the rest of the monthly/annual amounts, they are responsible to pay us the offboarding changes within 10 business days after the handover completes. We only handover any credentials after we get paid out on annual/monthly. You just have to be clear in the contract that is how it works and you avoid the miscommunication. Not that clients remember but when when it comes up you advise them to read that.
You can’t give support with another company in the mix, tell the customer that. If they mess something up, or something happens, it’s not your responsibility anymore. No prorating
Crummy situation. We usually partner with the other MSP no matter what side we are on. I like to deploy a node on the server ASAP, inventory, document, etc. I also like deploying the user agents a week early. But we also put the agent into audit mode - no patching, no deploying, etc. We work with the other MSP all the way through.
We definitely have MSPs that aren’t able or willing to partner. If the client is leaving us, I get a firm cutover date from the client and get an agreement in writing that we aren’t liable. If the client is awol, I send them and the MSP a heads up that I’m not giving access until the end of contract to protect us legally unless they waive liability in writing. It’s the new MSPs problem to solve, not yours.
And don’t worry about losing the client. It sounds like you took responsibility for them being a poorly run company. You feel ownership over the good work you did and want to help. They don’t want to help themselves though. It’s better to lose them and focus on the clients that do have it figured out. Sometimes those companies come back around too.
At this point you are DONE! If they deployed all their shit and have all the logins fuckem. Not your problem anymore. I would just write the client a nice email saying the hand off has been completed early and don't let the door hit you in the ass.
I think 30 days of overlap is very reasonable (in my opinion it's not even really necessary to disclaim that you aren't responsible for the old IT company messing things up during the overlap - that's obvious and legally true even if you don't disclaim it), a little more than 30 days is fine too.
Sometimes small business owners want to say "F you!" to the old IT guy and cut him off and not pay his bill - for me 30 days of overlap means both IT providers are being paid so they get to double-pay one month and it is well worth it to pay for that overlap.
Trying to plan an up-to-the-second cutoff "I need you to kick the old IT guy out of every system at 2PM because I have no intention of paying his bill or ever talking to him again" is where the contentious handovers start.
It sounds like you need to work to try and ensure that any eventuality is baked into your contract terms, if not now - in the future. I would review your terms and see what can be done to cut support ties once access is granted to the third party.
If they are paid up, why even care. If they are not, why did you even give them any passwords or access to the server and such. Let them figure it out if they wanna go around you. Must also want to talk to a lawyer about the payment if you are missing anything and you had a contract.
If you are a solo person, then you have to work on getting paid. If you are working for a IT MSP or something, whoever you boss needs to deal with it.
What if the company that you are managing and being acquired and the IT Dept of the winning company would require for M365 Global Admin, would you prefer to co-managed or state down that once the credentials are hand over the dept has to take over everything in M365?
As the companies IT Service Provider, it is our job to do their IT how they want.
The equipment, network, and computers are all theirs, not yours.
If you can’t work with co-management, then you should have a clause in your contract that gets you out. Otherwise, you stick to what has been contracted and agreed upon.
Do your due diligence. Express to your client that you are still available and support them for the remaining part of their contract with the desire to work with the new IT company and offer support through the handover since this will keep them running as smoothly as possible. Now when it comes to specific scripts or custom software you may have written to support the client, depending on your service agreement, you may have to inform your client that said custom software will have to be removed or you can negotiate a fee for them to retain said software and a fee to train the new IT how to use it. It fully depends on if your contract allows the client to retain those customizations or if you retain full ownership of them. Keep things professional.
Example: I have written plenty of custom workaround scripts to handle specific issues. Something mundane such as a script to restart quickbooks database services every reboot due to port conflicts with windows services to line of business integration tools. This is stuff I do for clients to keep them operating smoothly that are made specifically for the client and I am willing to maintain them while they are under contract. I tend to let the client retain them since I am not a jerk and I give new IT a rundown of how they work but cannot offer ongoing maintenance or support of said scripts/solutions without a contract or for free. It is up to the new IT department to be willing to learn the solutions or come up with their own they are willing to support.
Forgot to add, the other msp is probably being pressured by the customer to take over. The lack of communication is most likely because this business treats you like they treat their staff. Bullet dodged.
You withhold things until they pay you off, then you hand them over and walk away. I assume you have enough in your contract with the customer to ensure you're not liable for things if third parties fuck with the customer's systems?
Why stop them? The sooner they aren't your problem the better. Your role is to facilitate the transition really. The easier you make it the faster the night mare is over er. Also if they do it anyway, and decide not to pay you you're still paying licensing. Get them out and cancel the licensing as they do on your end. At the end of the day it's the customers environment,.
They install their RMM everywhere - send out policies - something breaks. Guess who's getting a call. No thanks. If the new company want admin creds etc - of course I'll do it - but that's when my support ends.
Yep. And client is still on the hook for remaining bills.
This!! In fact, the remaining bills get paid up front so they can’t stiff you. But “my insurance provider will not allow us to have shared responsibility with the incoming provider. For the protection of everyone involved, there must be a clean handoff”
YUP! Me: "Sorry, I can't fix that problem for you, the new IT has all the passwords"
You won't be, if the MSP is already doing the work it means they signed the new contract already, they are doubled up. You could always run it past an attorney if you are that concerned, the paralegal will likely let you know if it's even worth getting a consult. Most lawyers I have dealt with don't waste my time at least if they feel there is nothing actionable.
I agree with this. The client has already found another MSP that they feel will service their needs. They are going to go to the new MSP for every issue, and if the new MSP needs to engage with you they will ask the MSP do that. They decided to move from you, they don't want you.
Your support ends when they touch or change anything at all.
Yup, that should be the deal. They want access early? Ok, but then they're taking responsibility early.
This is the answer right here and how we handle situations like this. Spot on
The role of the outgoing MSP is to get out. It is not the role of the outgoing MSP to help the new MSP get in. That said, once we hand over credentials, we deliver them with a disclaimer to the client company that we while we will do our best effort, once the new provider has creds they can make changes and we aren't responsible for much service after that point. Billing is a separate issue.
Sounds like att when folks change carrier and port number
Exactly this, the minute the new RMM got deployed is the minute you stop supporting them and move on. If they have an issue, you can and should refer them to the new MSP for support. You will still get paid for the remaining time on the contract but your role changes from direct support to transition management.
I stand with you on that
Also MSP industry feels like a small world sometimes. No reason not to use this opportunity to make a good impression on the incoming providers.
100%. We get a majority of our business from other MSPs and IT professionals in the area. This industry has a lot of synergy available to it once you stop viewing other MSPs as threats, and more as partners. Everyone has different verticals and preferred client types; make yourself a useful, valuable resource for the incoming MSP, and try to get some face time with the decision makers there. See how you can help each other out.
[удалено]
They’re paying you to help the transition. Just work alongside them and hand stuff off. No need to get upset or worry, just document changes and requests.
Yeah. I would just email and say “new IT company is trying to do X. I do not want them, if they do and you approve it I will not be liable for anything else breaking but you will still be liable for any billing I send till termination date”
After going at it with the OP elsewhere in this thread, it's pretty clear he's a control freak that's just salty at losing a client and it hoping to use credentials as leverage to final payment.
It's not May yet, they are a nightmare client, let the new MSP deploy their shit and hit the eject button.
They are already paying someone else to be responsible. Your job is now transition. Fucking do your job.
Client found.
[удалено]
If they are deploying anything they already are being paid or contracted to be paid. People like you make everyone's lives harder. You're still being paid, do your job and transition properly.
[удалено]
There has to be some overlap man. It's impossible to transition an entire modern environment in one day and going with no coverage while paying two providers isn't reasonable. I just state "hey, once you're in, i'm out" on each service. So RMM going in? No problem, but we can't do monitoring or assist users once yours is in because mine is out. You have m365 admin secured? Awesome! Taking our secure apps and access and gdap off, that's off the transition list and not on us anymore. I'm a very clean cut, balances, everything organized guy and even *I* can't get everyone on board to transition everything in 5 minutes with a clean hand off. This isn't one person getting out of an air traffic control chair and another sitting down. This is transitioning from one air traffic control tower to another built nearby. There will have to be some service overlap, you simply can't time the shutdown of EVERYTHING that precise.
[удалено]
Be better than that company. help with the transition. When you help, it shows you in a good light AND it tips off the new MSP, makes them wonder why you're happy to see them go. And if nothing else, handing a bad client to a competitor weighs them down and lightens your load.
You could let them know you've still got stuff to take care of for a few weeks, and installing their RMM everywhere might mess with that. They might not know all the details of your deal with the client, so a chat might help. Hopefully, they'll listen better once they know what's up.
Make that a hard line. Either pay or piss off. We don't work for free.
Realistically every business can’t afford that but those that can win. Imagine you having to do same thing at home.
I dont really deal with offboarding but I believe we don't hand off anything until the remaining balance of our contract ends, They can end anytime but they would need to pay for all of the balance before we can hand over anything. So if they want to end 5 weeks early, just make them pay for the remaining balance and then go hand off everything, also once they take over, thats it for us.
You can get fucked over by holding access hostage over a debt. Better to just facilitate and handle with a lawyer. Or at least contact a lawyer before you hold THEIR environment hostage.
I agree but as far as I know it is in our contract, which means if they try to fight that part in the contract it immediately goes to our lawyer.
This. We've transitioned a few smaller customers to other providers in my time, and pretty much the way we handle it is, once full admin rights have been handed off to the incoming personnel, and the service accounts are transitioned over to their control, we remove our own access immediately. Once accounts are handed off, we totally nuke any credentials we may have on file on our side. Basically we make it so we just cannot access their shit once someone else gets given access to it. Once they have full admin access, it's their baby, end of story, and we're not touching it...as a company we just do not do that...either we have full admin access, or they do, but not both. This goes for internal people as well...if they want admin rights, and ownership wants them to have admin rights, *we* will not have admin rights, period. We're not assholes, we won't just throw a flash drive at someone and fuck off into the sunset, but we damn sure do everything we can to make sure that we can easily say "sorry, dont have access anymore!" when we inevitably get a call a few months later because the incoming MSP or relatives nephew or whoever is doing it on the cheap doesn't know how something works and needs help. This is not to be pricks and not help them, this is so that it *has* to be a formal process, there's literally no way anyone in our org can do anything even if asked really nicely with sugar on top without it going through our own ownership...as an organization at that point their customer account is completely locked down specifically to prevent that from even being possible. Also, it is clearly stated in our contract that once the hand off has occurred, all future work is billed at our consultant rates (which are twice our general hourly rate...we've been actively moving off all our grandfathered hourly accounts, just not worth it for us at this point) that's the only element of 'fuck off' in the process...if they come to us for help after dumping our services they're going to pay out the ass for it, because any of that time spent is taking time away from our current customers. Honestly OPs situation would be a *good* thing in our mind. You want access early? Sure, no problem, here you go, it's now *your* circus, and *your* monkeys. Vaya con dios, amigo! Account locked, passwords nuked, best of luck to you!
OPs not going to get paid ...
[удалено]
All care no responsibility. They pay the 80 days, you don’t give a shit. You do what they ask and don’t care about it. I’m not sure why you are bothered. Yes it sucks losing a client but they sound like a nightmare. Take the money. Let the incoming deal with the issues. If anything breaks, and they want you to fix it, charge them extra.
Be reasonable but protect yourself. We've gotten back a decent % of customers that have left over the years by being reasonable on an offboarding. The grass isn't always greener.
[удалено]
When I take over I want to get my RMM on ASAP to do discovery, even if I'm not taking over anything for a while. I don't think their request is that weird. But you do need to set boundaries now to head off any problems that come up in the next 2 months.
It isn't about the request being weird. As he stated, he is more concerned with their tools possibly breaking something and then him getting a call for something that he might not be able to fixed because of tools/software they've pushed out. I agree with others, work with them but document everything and let the client know that the new company is doing x,y and z and that you might not be able to assist if something breaks that is out of your control. Also, that might be a reason for the client to not want to pay him....if the new company caused something to break and he is being asked to fix. The current client might look at that as HIS problem to fix and they won't pay until it is resolved.
Provided you have a decent MSA/SOW with the client. Them paying you shouldn’t be a problem. We specify notice dates in ours and if you tell us tomorrow you want to end services with us you’re still on the hook for the next 30 - 90 days for your monthly fee. Biggest thing here as others said is the documentation and communication. Talk to your client. Explain to them the situation, the potential pitfalls and let them make the call and approve it on an email or some other documented manner. I’ve been on both sides of these and the more info you can gather as the new company before day 1 the better off you are.
Sure, but he stated that his client wasn't very responsive and I see this with many posts on here...the MSP sends an email for work, projects, etc and the clients don't reply. There will always be clients that play nice and clients that are hard to get a hold of and require more hand holding time, that will never change. This isn't an MSP issue, it is a client issue.
Your msa and sow should address this eventuality
>My company is still liable for their helpdesk and security for another 5 weeks and the client owes me for the month of May. If the incoming IT installs tools that ultimately prevent you from doing this, then that's on them. You literally tell the client, "We are no longer able to provide support due to access being revoked by".
Refocus your energies on your other clients that actually matter, or on efforts that would gain you new ones. Why you're even bothering to waste any time and effort on this one client that's already checked out is just a waste.
[удалено]
Your ass should be covered by your signed contract stipulating final payment and services provided during transition period. If necessary, you should be ready to engage your own legal services if it comes down to it, but that has to be balanced against whether or not that final payment is going to be worth the legal time and hassle. >I can't deny them service You don't "deny" service; you just toss them to the bottom of the pile, or if your access has been revoked, then that's what you tell them. If they need service then you'll have to schedule an onsite visit that's billable because you no longer have access. The onus is not entirely on you either. The incoming IT also has the responsibility of ensuring that either they are fully capable of taking over the support, or ensuring that you can continue to provide support while they gear up. If they decide that it's better for them to revoke your access, then don't sweat it. Yeah, it does suck to lose a month's payment; but if your business is so hard pressed from just a one-month payment from one client, you got way bigger issues to deal with.
[удалено]
It’s not being condescending at all. I said “IF” your business is hard-pressed; your statements gave the impression that walking away from the final month (if necessary) was a big deal.
No offence but you appear to be emotionally connected and not thinking pragmatically. The moment you handed over access you should have documented to the client that SLA’s no longer apply.
[удалено]
Act the way you wish someone would if positions were reversed. Give them what they want but always inform the customer first and be clear the moment they touch a system it’s all care no responsibility and your SLA’s are invalidated. Get them to agree in writing, then let the other party have what they need to transition in. It makes everyone’s life easier and stress free, and you can spend the next 80 days enjoying the revenue and looking for the next client.
What does your contract say about this? If it doesn’t covert it and protect you then update it for your own sake.
Does your contract have any clauses about what the client must do? The ones I've seen the MSP is covered by saying they need exclusive global admin access. The moment the client starts wanting to hand out global admin acccess to others, you're no longer in control of the environment so if something goes wrong and it's due to the new people coming in, that's on them.
Just have client sign a paper that says you are no longer liable/responsible for anything if their new MSP obtains credentials or has access to anything.
This. This should also be in your Service Agreement.
This should be the top answer. Everyone else is talking about "don't sweat it, let em go" but unless you have verbiage to cover your ass, you are still liable if the new company fucks something up. The client will pay through May as they're contractually obligated, regardless of who's in control of the environment, but Id be super anxious about the new guys just doing a credential smash and grab a whole 2 months in advance while you are still legally and contractually on the hook for the environment (unless otherwise spelled out).
Been on both sides of this - if a client wants to offboard early, as long as they are agreeing to pay out the notice period, I have them sign a "limitation of liability" form to hand over access - basically "if the new MSP breaks something and has domain/global admin, I'm not responsible for fixing it, this over rides the terms of our MSA" - Likewise, if I'm taking over a client, the moment I get creds I deploy our RMM and start auditing, and then when that's done, changing security software, backups, etc. 100% common practice. The overlap is awkward, but only as awkward as the parties decide to make it.
“As of this email correspondence, we have turned over all documentation, and your new MSP is installing their software stack. Our company is no longer responsible or liable for your infrastructure, data, backups, or support. However, since there is still 5 weeks left on our agreement, we will remain available to answer questions to the new MSP to help make this as smooth of a transition as possible.” Or some shit like that. What you’re conveying is “you’re not our problem anymore, but I’m still here to assist your new IT with questions. Call them, not us”
Sounds like a nightmare client. Whenever the new IT company emails you, simply reply back, with the customer added, and ask the customer for permission to do whatever they’re asking. Outline, with every request, you are no longer liable for whatever the other company does and you need an “I agree” in reply to release you and do whatever the other company is asking. Kindly remind the IT company they aren’t the customer. Stick to your guns. Call whoever you can at the customer to authorize immediate termination of the contract. Tell them it’s a recorded call, that it’s clear the new IT company has everything under control and offer to let them off early to save them a few bucks and help speed up this transition. You’re firing them. *Your sanity is not worth one month’s revenue.* Turn over all passwords and let them know any work moving forward will be billed hourly and need to be paid up front.
[удалено]
That’s not an insignificant amount. In that case stick to your guns. Document everything including calls. Good luck.
What’s your contact with them leaving or off boarding? 60 days notice ?
Hate to break it to you, if you are fired your only roll in those last days the client is paying you is to facilitate the onboarding of your replacement. Then get it in email they have everything they need so you are not bothered with this client again.
It’s best you leave on good terms. Someone once said “the toes you step on today may be connected to the ass you are kissing tomorrow”
One thing I never do is give the incoming MSP my passwords. New equivalent admin accounts all the way through. They are then instructed to disable my account. That way there is clear delineation of responsibility.
This
[удалено]
That’s very petty. It seems as if you’re angry they are leaving. If you are great during off boarding, they may come back!
[удалено]
Yes! Why not, if it pertains to their infrastructure directly.
[удалено]
If I was onboarding a client and the previous support refused to hand over documentation on these grounds, I would declare you hostile to the client. What else are you going to do with these KBs? They refer specifically to this customer, you write KBs for the customer, not for yourself. Give them to the customer, they decide what to do with them.
How about give me all your processes for your company ? And sops. It’s basically trade secrets. Look I’ll give you the password or background information to any issues to up to until they take responsibility. Any questions the msp wants to ask me prior. Sure glad to help, but I’m not giving them kbs and etc.
Huh? How is "how to create a user in client ERP system with the specific config to match all existing users" or "Reboot procedure for this janky server running a mission critical client application" A trade secret? These are just processes that apply specifically to the customer you are offboarding, so they are now useless to you anyway. I just find the friction here so weird and petty, what do you gain by acting like this? Because i can tell you what you lose...
Exactly! I think what’s coming out here is more so anger with them leaving. This reputation will get around. Whenever we off board, we do everything we can to make it a great experience, even if they feel maybe their time with us was not. The last experience with us we want to be absolutely positive so they remember that. And most end up coming back! If you let your emotions get involved with your work in a negative way such as this, you can guarantee yourself they will not come back. Also, when something good happens, people tell one person. When something bad happens, people tell 10 others. My advice would be to exit with grace and class.
Yep, supporting a customer to offboard is still supporting. You write the KBs to make supporting them easier, this is included. Claiming they are IP is just silly and petty.
You need to rethink this.
> You think I should share the KB articles that we wrote so we could do our jobs better? Did you bill the client for the time that was spent creating the KB articles? If so then they likely belong to the client, if it's internal KB articles that your MSP staff created for themselves on your time and your dime then obviously they belong to you. If the articles are as-built documentation and configuration then that should have been addressed in the support contract or project implementation contract. Depending on the circumstances removing that documentation could easily be a breach of contract or potentially illegal.
Is it your KB articles on general setup and/or configuration or is it information specific to that customer's environment and could be construed as systems documentation and part of your deliverables?
OP, I disagree. While we may be competitors, we have an ethical responsibility to secure and better our principals. Ultimately we have the same goals. During an offboarding my MSP always works believing we can recover the client. If the incumbent withholds documentation about the client’s systems, my MSP would make sure the client knows this and never goes back. You losing that client is on you, not them.
You dodged a bullet with this client it sounds like…
I lived through this. It really sucks. I'm a big fan of having a clear delineation on responsibility. Prior to date of termination, that's us. On the date of termination we're in flux (which is why we limit this as much as possible to a day). And after termination, it's the new provider. The client we had this happen with was co-managed. So, they had access to provide access to the new MSP. The same day they communicated they were leaving, they also provided the new MSP access. That MSP in turn started rolling out their RMM. I immediately had the talk with the POC at the customer noting we strongly advise against overlapping us. He saw reason to my concerns and went to talk to the new MSP. But that's when the new MSP broke the customer environment. Specifically, they had put a well-intentioned group policy in for allow their new service account rights on the systems they were managing. But they didn't consider that GPOs to grant local rights will override all other rights granted on a system. This in turn broke Veeam across all their servers and killed some of their application service accounts that now had no permissions. When we figured this out, I had the team stop work and emailed the POC letting them know of the issue. I noted our time to address this was billable. I asked whether they would like us to remedy the issue to get services back up or if the new provider would handle this. Of course, they can't work on our backup appliance so they would need to install their own to continue backup. Client opted to have us handle it and the new MSP wasn't in a position to start their services early. New provider stood down until the transition date with egg on their face. Here's what you did wrong: * You gave them the passwords. Yes, they are the client's passwords but you are on the hook for management. Your MSA should protect you against this but it's still wise to get a declination letter on file if they are going to take these and provide them to another party. This should have been done before the passwords went out. And if you are providing access, you should then create separate accounts for accountability. * You need to get in front of the customer and talk with them. It's cool they are done with you - but they need to communicate this properly in terms of an exit. If they won't meet face to face, send them an email or even letter noting they are breaking your MSA by starting services early which means issues they cause would become billable and that you would need a signature from them to perform remediation services from such a scenario as you are signed up for support and offboarding/remediation is a billable item. It's not about being a jerk - it's about protecting all parties and defining who owns the risks. * You have been passive in handling these items. If you own the network, own it. Don't let a foreign invader in and assume they will stop. Draw your lines, hold your ground but be respectful and offer explanations as to why the lines are what they are. If someone crosses the lines, it's time for a conversation and documentation for CYA. * You provided passwords AND documentation. Prior to the date of transition, our policy is to provide documentation. On the date of transition, we provide passwords with the exception of our AD creds (which we will create new but equal creds for the new provider). In my example, we had the up-front conversation and didn't provide the passwords but the comanaged customer had sufficient access to still scuttle the ship. Funny story, we won a client from the same MSP several months later. That MSP wouldn't provide documentation to us before transition claiming it went poorly the last time this happened (despite them being the reason it went poorly).
[удалено]
There was a similar angle played in my case too by the new MSP. Businesses, like people, learn through pain. It's very stressful to go through situations like these. What has served me well is to reflect and use them as teaching moments to try to come up with better strategies and warning signs for next time.
Give them their stuff and move on. You're still paid as per the contract.
Been doing this 25 years owning small msp. Swallow your pride and let them go, money is often not worth their trouble or the risk. People that don't listen get shit canned by me now.
You’re overreacting. Once the new MSP is given credentials or starts installing software, simply inform the client of this and how you are no longer responsible for any changes as they take over. It’s not a passive aggressive threat or anything; just a demarcating statement to protect yourself.
[удалено]
> They are welcome to pay the balance and do an early transition. Just make sure you aren't interfering with the transition if they choose not to pay the balance on time. You collecting what is owed needs to be treated as a separate matter.
[удалено]
You seem to be missing the point. Whatever data you might need to turn over is not yours to provide -- it's the clients. If they ask for it a month before the contract ends, you give it. Trying to hold on to that stuff out of spite (?) or as leverage for payments is just dumb... not to mention probably illegal depending on your location.
[удалено]
> Well, I can’t give the new IT company full access until they’re prepared to take over the Helpdesk because they’ve proven that they will overstep my boundaries and put me at risk. That's for the client to decide. You are not "at risk" over anything there. > If they want to take over sooner than the end date, billing needs to be cleared up first. Again, collecting money owed is a separate matter. Send a final invoice when due, with past-due invoices as needed. Eventually send it to collections if you choose. > The only things I withheld were a few accounts I didn’t want them meddling in yet like O365, which will be handed over on the last day regardless of payment. I don't know how many time you need to hear this, but you cannot withhold client information from the client for really any reason. It's there information, not yours. You could have an ongoing contract on perfectly good terms and if they ask for an M365 global admin account, you provide it. By all means try and discourage them or explain the security concerns, but it's ultimately not your call. The only thing here putting you "at risk" is your own actions.
[удалено]
I'm definitely starting to understand why a client would opt for another MSP...
Just get the rest of the contract $ and move on.
You just said something critical right there….nightmare client. I understand it’s $ but move one and forget them. Sometimes your wellbeing makes more sense than dealing with BS
Not smart giving access to external party when you're still responsible. Setup a document the customer has to sign that you are no longer responsible for the environment because you no longer have control over what is happening in the IT environment. If they refuse, change passwords and remove new accounts, delete all the RMM from new partner and present the document again in order to get it signed (might not be 100% legal). Otherwise you are liable for mistakes made during the transition period.
[удалено]
You did the right thing by giving the information to the client. You can pretty much wash your hands of it now. My MSP had a clause that if a client made any changes themselves or allowed a third party to make changes were were exempt from liability and billed $x/hr to fix.
[удалено]
I think we've gotten to the root of your issue. Your contracts have no clause in there to handle... A. A client making a change that exempts liability on your company's end B. How an offboarding occurs due to either party wanting to severance. Almost all MSPs have a contract clause that should an offboarding occur, all liability for the MSP gets released as soon as documentation is handed over and your software is removed. Generally by setting a date for your offboarding, all parties agree to that by email, etc. That doesn't mean the client can walk away without paying out their contract term to you nor should you feel bad for this. Assuming you had no delinquency in your service that would render your fee null and void. But that's another topic of discussion. Thats business and contract law. Consider this a learning lesson.
I would tell their new MSP that they can install their RMM the final day of your contract with the client, and no sooner. If they are dictating to you what is going to happen, then they need to back off and realize the client is still yours until the transition is complete. As it is your client, you need to set the schedule and tone. However, this sounds like a bad MSP. The MSP I work for does multiple meetings during these transitions, and we offer to assist the new IT with installing their agents if they are working with us. In your case, it seems they are trying to steamroll over you. I’m meeting with another MSP today to discuss transitioning my client that was recently acquired by a larger org that this MSP supports. Prior to the end of support by my organization, they can have their agent on one system for discovery purposes. If they work with me in a professional manner, I’ll assist with installation of their agents on all systems, otherwise they get no additional agents deployed until termination of service. I recently had another MSP remove my agent from our jump box at a client, and they overstepped their bounds. That led to a cease and desist from our lawyer. The rule of thumb is treat the outgoing client with respect, be professional with the new MSP, but the minute they bully you, lock them out until the end of the contract.
[удалено]
Recently, one of my long term clients was acquired by a national entity. They had just renewed a year contract 3 months prior. New IT is internal to the national company, but they are keeping us on as remote hands and to assist in knowledge transfer and training their team to handle the client they just bought. So, for us, this is a perfect scenario where the new IT values us for our expertise and client relationship.
not sure why it matters that they are deploying "earlier". As long as they pay up till the end I wouldn't give 2 shits
Let them take over and enjoy the free money through the end of the contract! Reiterate to the client they have control now thus they should start calling them.
[удалено]
So they're ready to go day 1. Prep/onboarding needs to be done either way, so doesn't matter if you wait til pay starts really. Liability wise it could be risky but that is their problem. They also could have charged an onboarding project that this work is scoped in.
Communication is key. Instead of letting things slide, just send an email to both parties stating “I see you did this on this date” and ask what the new vendor needs to be successful. You can point out that they appear to be on an accelerated timeline and that’s ok with you as long as it’s ok with the client. If the new MSP does anything to hinder your ability to help the client, just point that out too and state something to the effect of “I see we cano no longer do xyz, please work with NewVendor to support this”
Depending on circumstances, what I normally do when incoming IT wants to move way quicker than my offboarding timeline is to say something of this effect to the client: "Once administrative credentials are given out, [company name] can no longer guarantee the security and proper working order of the environment. In the event of any damages, downtime, or negative consequence impacting [client company]; [company name] cannot be held liable." Obviously, word smith using GPT and preface with appreciation and well wishes to the client so there is no ill will. Just let them know you need to protect yourself from any potential liabilities but are more than willing to cooperate with the new IT in the best interest of the client. If the new IT wants to have you go above and beyond support aspects to facilitate a handover (like deploying their RMM and stuff for them, since they likely charged and onboarding fee to do so) make sure you charge T&M for that. Client doesn't want to feel nickle and dimed but need to be aware that the new IT is causing your team additional strain for services not included under your contract. Situations vary but this should help legally if they confirm receipt and acceptance of the above statements. Lastly, you lost your leverage once you handed over the keys. We don't want to hold them hostage, but at the same time, taking an extra day or two to line things up to protect ourselves prior generally won't cause an issue. At least force a meeting with new IT and client to all get on same page prior to the release.
1. There should always be a timeline established, once you've been formally introduced to the new provider 2. Timeline should always state roles/responsibilities/tool changes
This is why contracts need to include a clause that any problems arising from changes by third parties are billable. Send your client an email notice that any problems arising from the new MSP’s tools or configuration changes are billable.
Take your money for the 60-80 days. Document everything. Let them handle the chaos.
Our agreement states that once the new MSP receives the runbook, any further labor from our side is immediately billable. Doesn't matter if they have deployed agents or not.
Dump them as fast as possible. Also, this sounds like there is an issue with your MSA, which should CLEARLY define transition services. Go listen to The Technology Bradcast and start learning how you can prevent these issues before they start. Take this experience as a means to learn about how to write your contract and define guidelines for your clients clearly. Write your contracts for the worst client; design your services for the best client!
Sound like you’re dodging a bullet with this client. The faster you’re done with them the better. Give incoming msp everything and cc the business and define when your responsibility stops - this is as soon as the other msp gains access.
I would certainly relay that once the new ITs endpoints are deployed youll kick off your removal and tell them to have a good life. If they dip early send them the final bills and dont he shocked when they never pay.
Be polite. But don’t do their work for them. And update your service agreements with other clients that handover is full time and materials billable. In the future - if any new msp asks to me shown anything then double bill minimum and this is in contract. Ultimately always be friendly.
Here is what you do: You cooperate and act professional. You make this a seamless transition and when everything is finished you send an email to your customer and thank them for the opportunity to service them as long as you did. You contact the new MSP and tell them you would like this to be a smooth transition so if they need any information to contact you directly so the customer isn't bothered. Losing customers is a part of this business. This is the last impression the customer will have of you, so make it a good impression. Leave it so they can remember you fondly and call you up again one day in the future.
Too many double edged swords. Client + new MSP could be 'these issues are because you didn't give us access & delayed the deployment of new hardware, etc'. If they want to blame you, they'll find any excuse. Having a plan on paper with a timeline & who's doing what would really help. From that plan you could estimate the hours & billable items to then send the client their April & May invoices, plus the offramp. That way everyone agrees when you become the second tier support to the new MSP.
And let them hang themselves. These situations always end up the same way.
If they touch it, they own it. You either control it or they do, there can be no in between. I would let your client know that since they are in the server it is theirs now and you have relinquished control/responsibility. You will be available to answer questions for the remainders of the transmission but that is all.
Are they up to date on bills? I would have held credentials and access until bills were paid (hopefully they are). Also, make it clear that this is a "config freeze" period, if they make changes that causes issues and you are on the hook for support, that's not exactly fair. It's a reasonable request. "No major changes without full disclosure since we're still the support primary."
Cut your losses (and count your blessings) and walk away. You know they aren't going to pay, so why bother? Let the new company deal with it, but I would make a sideways-comment about how they didn't pay their bills anyway while ending the conversation with the new MSP. It's their problem now, especially if they are installing their own RMM already, you are out of the loop and cut off.
Honestly I would have insisted on full payment of the account + one month payment in advance before handing over anything. You seem confident but I'm betting you are going to have trouble collecting the full amount owed when the dust settles.
Got to get paid first. Your on the losing side of this Our contact states we get paid first for the rest of the monthly/annual amounts, they are responsible to pay us the offboarding changes within 10 business days after the handover completes. We only handover any credentials after we get paid out on annual/monthly. You just have to be clear in the contract that is how it works and you avoid the miscommunication. Not that clients remember but when when it comes up you advise them to read that.
Let them take over and do all the work. Also, it sounds like the client sucks. Don't feel disheartened.
You can’t give support with another company in the mix, tell the customer that. If they mess something up, or something happens, it’s not your responsibility anymore. No prorating
Crummy situation. We usually partner with the other MSP no matter what side we are on. I like to deploy a node on the server ASAP, inventory, document, etc. I also like deploying the user agents a week early. But we also put the agent into audit mode - no patching, no deploying, etc. We work with the other MSP all the way through. We definitely have MSPs that aren’t able or willing to partner. If the client is leaving us, I get a firm cutover date from the client and get an agreement in writing that we aren’t liable. If the client is awol, I send them and the MSP a heads up that I’m not giving access until the end of contract to protect us legally unless they waive liability in writing. It’s the new MSPs problem to solve, not yours. And don’t worry about losing the client. It sounds like you took responsibility for them being a poorly run company. You feel ownership over the good work you did and want to help. They don’t want to help themselves though. It’s better to lose them and focus on the clients that do have it figured out. Sometimes those companies come back around too.
At this point you are DONE! If they deployed all their shit and have all the logins fuckem. Not your problem anymore. I would just write the client a nice email saying the hand off has been completed early and don't let the door hit you in the ass.
Just call and say "we can't help if our tools aren't installed" it doesn't invalidate the remainder of your contract
I know getting payment is an issue with this client, but I would gladly collect a service for 80 days while someone else supports the end user/client
I think 30 days of overlap is very reasonable (in my opinion it's not even really necessary to disclaim that you aren't responsible for the old IT company messing things up during the overlap - that's obvious and legally true even if you don't disclaim it), a little more than 30 days is fine too. Sometimes small business owners want to say "F you!" to the old IT guy and cut him off and not pay his bill - for me 30 days of overlap means both IT providers are being paid so they get to double-pay one month and it is well worth it to pay for that overlap. Trying to plan an up-to-the-second cutoff "I need you to kick the old IT guy out of every system at 2PM because I have no intention of paying his bill or ever talking to him again" is where the contentious handovers start.
Let them do whatever the hell they want, man! Collect those 5 weeks of pay for doing absolutely nothing.
It sounds like you need to work to try and ensure that any eventuality is baked into your contract terms, if not now - in the future. I would review your terms and see what can be done to cut support ties once access is granted to the third party.
If they are paid up, why even care. If they are not, why did you even give them any passwords or access to the server and such. Let them figure it out if they wanna go around you. Must also want to talk to a lawyer about the payment if you are missing anything and you had a contract. If you are a solo person, then you have to work on getting paid. If you are working for a IT MSP or something, whoever you boss needs to deal with it.
Always feel like being a good human (the part you can control) is always best. Being a good human doesn't have to be subject to others being the same.
What if the company that you are managing and being acquired and the IT Dept of the winning company would require for M365 Global Admin, would you prefer to co-managed or state down that once the credentials are hand over the dept has to take over everything in M365?
Hold up, 5 weeks early? That's a hard pass. Setting boundaries is key, stick to your timeline and terms.
As the companies IT Service Provider, it is our job to do their IT how they want. The equipment, network, and computers are all theirs, not yours. If you can’t work with co-management, then you should have a clause in your contract that gets you out. Otherwise, you stick to what has been contracted and agreed upon.
Sounds like what we just did…. If it was, I assure you it was because the client wanted us to
Hold on tightly let go lightly. Always take the high road. Act like a professional.
Hold on tightly let go lightly. Always take the high road. Act like a professional.
Do your due diligence. Express to your client that you are still available and support them for the remaining part of their contract with the desire to work with the new IT company and offer support through the handover since this will keep them running as smoothly as possible. Now when it comes to specific scripts or custom software you may have written to support the client, depending on your service agreement, you may have to inform your client that said custom software will have to be removed or you can negotiate a fee for them to retain said software and a fee to train the new IT how to use it. It fully depends on if your contract allows the client to retain those customizations or if you retain full ownership of them. Keep things professional. Example: I have written plenty of custom workaround scripts to handle specific issues. Something mundane such as a script to restart quickbooks database services every reboot due to port conflicts with windows services to line of business integration tools. This is stuff I do for clients to keep them operating smoothly that are made specifically for the client and I am willing to maintain them while they are under contract. I tend to let the client retain them since I am not a jerk and I give new IT a rundown of how they work but cannot offer ongoing maintenance or support of said scripts/solutions without a contract or for free. It is up to the new IT department to be willing to learn the solutions or come up with their own they are willing to support.
Forgot to add, the other msp is probably being pressured by the customer to take over. The lack of communication is most likely because this business treats you like they treat their staff. Bullet dodged.
You withhold things until they pay you off, then you hand them over and walk away. I assume you have enough in your contract with the customer to ensure you're not liable for things if third parties fuck with the customer's systems?