Suppose we have a ticket with estimation of 4 units and this ticket was half done in one sprint and half done in next one.
Should we do re-estimation and when?
Don't re-estimate.
Change estimation at the end of sprint, close it and move ticket to another one.
Close sprint, move ticket to another one and then re-estimate.
What is correct way? Ho can Jira reports know about a progress?
It's up to the team to determine if or when to reestimate. Understanding why the team is estimating and what they hope to use estimates for is necessary to understand if the team should be estimating or reestimating. In my experience, estimation is almost never a value-adding activity and is unnecessary. However, if the team chooses to reestimate the remaining work, the best time within the Scrum framework to do it would be between the Sprint Review and the Sprint Planning events. One opportunity could be associated with the Sprint Retrospective, since if the team is estimating work, they may wish to discuss issues that prevented them from completing the work while reestimating the undone work items.
Specifically with Jira, I would perform the reestimation after closing one Sprint (which is typically done just before or during the Sprint Review) and before starting the next Sprint (which is typically done at the conclusion of Sprint Planning). When you close a Sprint, you can opt to move undone work into the next Sprint or into the Product Backlog - either would be fine, since the initial Sprint issues and estimates aren't "locked in" until the Sprint is started. This should maximize the value you get out of the Sprint level reports. Note that this is exclusively about effective use of Jira, other tools may behave differently, and the use of specific tools is outside of the Scrum framework.
This question isn't an exact duplicate of a ton of related questions as linked in a comment on the OP, but it is both highly similar to a ton of related questions about tracking incomplete work especially within JIRA and mostly an X/Y problem because it assumes incorrectly that work is permitted to automatically "roll over" across Sprint boundaries within the Scrum framework.
Since this question or ones like it are founded on an initial fallacy (e.g. that items from the Product Backlog can or should automatically roll over across Sprint boundaries), the shortest response I can think of is that:
Given the above, you should treat both the Sprint Goal and all work within the Sprint as binary, e.g. done or not done per the Definition of Done. Anything "not done" is returned to the Product Backlog as potential future work based on:
What you should never do is allow a tool (in this case, JIRA) to drive your process. Tools support a team's optimal (or at least chosen) process, but should never define it for you.
By trying to define success as a JIRA report on effort expended or "progress" towards some abstract definition of completion rather than as a binary outcome, you have inverted the delivery-oriented aspects of agility. In other words: Do you have a potentially-deliverable feature or not? If the answer is no, then "progress made" or "effort expended" are irrelevant metrics.
While one might make an argument for work or effort remaining to delivery a given outcome, these need to be re-assessed in the present rather than based on some historical starting point. That is why user stories shouldn't carry history, and why historical estimates should be discarded in favor of future-facing estimates—assuming that the work in question remains useful or valid at all, which is not a given within any agile framework.
Close sprint, move ticket to another one and then re-estimate.
In case of any delays like this,it will be a good culture to close the sprint and re-estimate to avoid team from spending more than enough time on a sprint.
