A good thing to do is look at most languages' String class. Strings in any language I can think of are immutable, but most of the time nobody has any problem working with them. It's good to think of the ways in which you interact with Strings and ask yourself if you can work on your class in the same way.
For example, if you want to take a String and replace all instances of upper case letters with lower case ones, there's a .toLower() method or something similar which returns a new String object that is a copy of the old string object. The original String stays the same. You can do similar things with most objects. Let's say you have a class that represents events for a venue. Currently, there's some really hip Bourbon tasting event that is set to go down on Thursday, but for whichever reason the event organizer needs to change the date of the event to Friday instead. Replace the old event with another one that has the date field changed from Thursday to Friday:
bourbonTasting = bourbonTasting.replaceDate(DAYS.Friday);
So that's all fine and dandy now! Anything that is looking at the 'bourbonTasting' variable will now read that it is on Friday rather than Thursday.
The thing that becomes hard with immutability, however, is that since you didn't mutate the original anything else that was storing a copy of the old event needs to be updated. Now imagine there's a bunch of calendars out there that have this event on them. If they all had a reference to the original object, and the original object were mutable then these calendars wouldn't need to be updated because the object they were all pointing at would just have the new value. That poses a lot of problems with concurrency though, since if something is looking at that calendar and something about the event changes mid-way though, the person consuming that calendar could be left in an inconsistent state. These are side effects of mutating that object.
Since our hypothetical calendar event IS immutable though, we don't need to worry about changing things out from under people without them noticing, but what we DO have to worry about is how to update all of these calendars. In this case, it would be good to have the person 'subscribe' their calendar to the event. When the event changes, a new event can be pushed to those calendars. If those calendars are immutable too, then they will need to be recreated with the new event replacing the old one, too. If the list of subscribers to the event is immutable, a new subscriber list needs to be created any time someone new subscribes.
As you can see, having everything be immutable can clean up concurrency problems, but it can also get expensive. You can wind up having to create a lot of new objects just because one little thing changed. The key to using immutability well is knowing when to use it, and when to not. The event object is a very public detail and having it be immutable is probably good, so that you don't change things out from under people. The list of subscribers for the event can likely be kept private to the event or the event organizer, so it might make sense to keep that be mutable so that you're not doing a crazy amount of recreation of objects if you have a hot event. The calendars of people planning on attending the event could go either way, depending on what else the calendars are being used for.
It's one of those things where you have to be sound about paying attention to both object creation and consequences of change, and make a rational decision based on the balance of those two factors. If it's going to be expensive to keep creating new objects and it wouldn't be difficult to manage who is looking at the objects, it might be better to keep it mutable. If the key is avoiding side effects, and/or object creation isn't going to be relatively expensive, it should probably be immutable.
So, if you're running into situations where you're struggling with immutability, first make sure you're thinking of immutability correctly. Think about it like String, and how you operate on that. If you're already working in that right mental model, then it's time to start asking yourself if immutability is the right thing to be doing. If creating and replacing objects is painful, maybe immutability isn't right for that particular case.