I have two separate applications running on heroku and pointing to same database, first one responsible for user interface
and second one for admin interface>
Mike's answer is still a safe bet, though having to include all relevant sidekiq options inline everywhere you enqueue this class is a bit gross.
Here's a blog post that goes into more detail, and offers a second approach:
http://coderascal.com/ruby/using-sidekiq-across-different-applications/
Basically the alternative is to have a "proxy" class on the enqueueing application that controls the sidekiq behavior (queue, retries, etc.). Then there would be a matching class name on the receiving/de-queueing application.
The author of the blog post overrides some standard Sidekiq logic to redirect from the proxy class to the non-proxy class on the receiving side. Overriding the gem's behavior is a bit risky, and it enforces an extra convention on your class naming. But you may be able to get away with not doing that part.